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ABSTRACT 
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comptroller  departments  in  the  development  of  an  automated  financial  management 
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I.  INTRODUCTION 


A.  DISCUSSION 

The  Department  of  the  Navy  has  assigned  the  responsibilities  of  managing 
appropriated  funds  down  to  the  level  of  the  Commanding  Officer  of  a  unit. 
Accountability  for  managing  financial  resources  is  established  by  federal  law 
(Title  31  United  States  Code).  Specifically,  Title  31  of  the  U.S.  Code  on  "Money 
and  Finance"  has  two  sections  that  directly  influence  the  use  of  appropriated 
funds.  Title  31  U.S.  Code  Section  1301  requires  that  appropriated  funds  be 
obligated  for  the  intended  purpose  that  Congress  specifies.  And,  Title  31  U.S. 
Code  Section  1517  prohibits  any  government  employee  from  obligating  in  excess 
of  the  amount  authorized.  A  violator  of  Title  31  Section  1301  or  1517,  either 
willfully  or  unknowingly,  is  subject  to  disciplinary  action  or  criminal  penalties. 
[Ref.  l:p.  A22,  2:p.  10] 

Congress  has  sent  out  a  clear  message  to  all  DoD  activities  with  passage  of 
Title  31  U.S.  Code.  That  is,  all  activities  must  manage  their  financial  resources 
accurately  enough  to  ensure  that  all  appropriated  funds  are  obligated  in  a 
manner  to  prevent  a  violation  of  Title  31.  To  do  this,  an  activity  must  be  able  to 
recognize  it’s  financial  position  and  be  able  to  monitor  it’s  progress  while 
executing  the  activity  financial  plan.  Without  this  capability,  it  is  difficult  for  an 
activity  to  manage  it’s  resources  effectively  and  not  incur  a  Title  31  violation. 

This  highlights  the  importance  of  an  effective  Financial  Management  Information 
System  (FMIS).  A  FMIS  needs  to  be  able  to  provide  the  needed  information  to 
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management,  so  that  a  manager  can  effectively  allocate  available  funds  and  at  the 
same  time  meet  the  requirements  set  forth  by  Congress. 

B.  OPERATING  ENVIRONMENT 

1.  Source  of  Appropriated  Funds 

The  Navy  Comptroller  (NAVCOMPT)  is  responsible  for  the  financial 
management  of  appropriated  funds  allocated  to  the  Department  of  the  Navy 
(DoN).  NAVCOMPT  receives  funds  from  the  Secretary  of  the  Navy,  and 
distributes  these  funds  to  major  claimants.  A  major  claimant  is  a 
bureau/office/command/headquarters  that  is  designated  as  an  administering 
office.  And  is  assigned  specific  budgeting,  accounting,  reporting,  and  budget 
execution  responsibility.  Subclaimants  are  commands  designated  to  receive  a 
subclaimant  operating  budget  from  a  major  claimant.  [Ref.  l:p.  B21] 

Major/sub  claimants  redistribute  funds  to  responsibility  centers  (i.e., 
shore  commands)  via  allotments.  An  allotment  is  the  authority,  expressing  a 
specific  amount  of  funds,  for  an  activity  to  commit,  obligate,  and  expend  funds 
for  a  specified  purpose.  An  allotment  is  provided  to  the  activity  by  NAVCOMPT 
Form  2168-1  Resource  Authorization.  In  addition  to  the  funds,  the  NAVCOMPT 
2168-1  also  specifies  the  legal  limitations  and  restrictions  placed  on  the  funds. 

The  responsibility  center  is  the  lowest  level  in  an  organization  that  the 
legal  responsibility  under  Title  31  can  be  assigned.  The  Commanding  Officer  of 
a  responsibility  center  retains  the  full  legal  responsibility  under  Title  31.  A 
responsibility  center  further  divides  the  allotment  into  operating  targets 
(OPTARS).  OPTARs  are  administrative  redistributions  of  funds  to  the 
departments  or  divisions,  called  "cost  centers",  within  a  responsibility  center. 
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Cost  centers  operate  within  a  set  of  policies  and  procedures, 
established  by  a  responsibility  center,  to  control  the  obligation  of  funds.  While 
cost  centers  are  not  directly  subject  to  Title  31,  an  inadequate  system  of 
administrative  controls  on  the  use  of  OPTAR  funds  can  lead  to  an  over  obligation 
of  funds  at  the  activity  level,  thus  exposing  the  responsibility  center  to  a 
violation  of  Title  31. 

2.  Accounting  System 

A  Financial  Information  Processing  Center  (FIPC)  is  an  activity  that  is 
assigned  the  task  of  performing  official  accounting  and  disbursing  for  a 
responsibility  center,  including  maintaining  official  accounting  records,  civilian 
payroll,  and  bill  paying. 

The  FIPC  is  a  disinterested  third  party  that  consolidates  financial 
transactions,  and  provides  official  accounting  reports  to  higher  authority  (i.e., 
major/sub  claimant).  Major /sub  claimants  depend  primarily  on  these  official 
accounting  reports  to  evaluate  budget  execution  performance  of  a  responsibility 
center.  Throughout  the  year,  the  mfgor  claimant  reviews  the  responsibility 
center’s  obligation  rates,  unliquidated  obligations,  and  unmatched  expenditure 
rates  to  determine  whether  to  recoup  or  grant  additional  funds. 

A  responsibility  center  that  receives  Operations  and  Maintenance 
Appropriation  (0,M&N)  allotments,  operate  under  the  Navy’s  Resource 
Management  System  (RMS).  RMS  is  the  formal  Navy  system  that  tracks  and 
accounts  for  financial  resources  assigned  to  responsibility  centers.  A 
Responsibility  center  that  operates  under  RMS  is  referred  to  as  an  RMS  activity. 

Responsibility  centers  and  cost  centers  each  maintain  local  accounting 
records  called  "memorandum  accounts".  The  memorandum  accounts  are 
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maintained  to  monitor  the  use  of  funds,  and  are  the  source  documents  for  the 
reconciliation  against  official  FEPC  records.  They  are  not  recognized  as  the 
official  records  because  they  are  not  directly  visible  to  the  major /sub  claimant. 
[Ref.  2:  p.  21] 

3.  Integrated  Disbursing  and  Accounting  System 

The  Navy  Accounting  and  Finance  Center  (NAFC)  in  Washington, 

D.C.  was  designated  as  the  project  office  for  the  Integrated  Disbursing  and 
Accounting  system  (IDA).  NAFC,  was  to  develop  an  automated  system  that 
would  consolidate  and  standardize  Navy  accounting  practices.  In  October  1989 
DoN  was  notified  that  the  Secretary  of  Defense  was  reviewing  the  issue  of  a 
standardized  Department  of  Defense  (DoD)  integrated  accounting  system.  In 
December  1989,  as  a  result  of  this  review,  further  development  of  all  accounting 
systems,  including  IDA,  have  been  cancelled.  IDA  will  ultimately  be  replaced 
with  a  DoD  accounting  system. 

EDA  is  the  automated  accounting  system  that  is  operated  by  the 
FIPC’s.  With  the  cancellation  of  the  IDA  project,  the  intended  consolidation  and 
standardization  of  the  various  automated  systems  at  the  different  FIPC’s  will  not 
be  completed.  Therefore,  field  activities  will  have  to  operate  the  currently  in- 
place,  not  fully  developed,  EDA  system  until  the  new  DoD  system  comes  on  line. 

4.  Official  Accounting  System  vs.  Unofficial  Accounting  Systems 

There  are  two  reasons  for  maintaining  unofficial  accounting  records  at 
the  activity  level.  First,  the  IDA  accounting  system  is  never  up-to-date  [Ref. 

6:pp.  5-6].  There  is  a  lag  between  the  time  an  obligation  is  created  and  when 
the  IDA  system  posts  the  transaction.  This  delay  is  due  to  IDA  being  a  batch 
oriented  processing  system.  (Ultimately  the  final  version  of  IDA  was  to  resolve 
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this  problem  by  going  to  an  on-line  system.)  Therefore,  the  current  IDA  system 
does  not  provide  real-time  account  balances. 

Second,  the  IDA  accounting  system  is  inaccurate.  These  inaccuracies 
can  be  attributed  to  human  input  errors  at  either  the  FIPC  or  at  the  local 
command.  Presently  the  only  way  to  identify  and  reconcile  these  errors  is  with  a 
second  accounting  system.  [Ref.  2:pp.  27-30] 

The  second  unofficial  accounting  system  exists  at  the  cost  center  level. 
The  cost  centers  have  the  same  motivations  as  the  Comptroller  to  maintain 
their  own  accounting  records.  These  accounting  records  are  unofficial  but  vital. 
The  cost  centers  are  routinely  tasked  by  the  Comptroller  to  reconcile  transaction 
listings  and  research  discrepancies.  Cost  centers  also  have  the  need  to  know 
their  current  OPTAR  balance  on  a  daily  basis. 

All  three  accounting  systems  are  necessary  to  be  able  to  keep  track 
and  maintain  accurate  financial  accounts.  The  m^jor  claimant  recognizes  the  IDA 
records  and  account  balances,  which  in-turn  requires  the  shore  command  to 
ensure  that  IDA  is  accurate.  There  will  always  be  two  unofficial  accounting 
systems  within  the  commands  to  support  and  validate  the  official  system,  and  to 
meet  their  internal  financial  management  information  needs. 

C.  PURPOSE  OF  RESEARCH 

The  primary  purposes  are:  to  determine  what  attributes  should  be 
incorporated  in  a  Navy  shore  activity’s  Automated  Financial  Management 
Information  System  (AFMIS);  review  currently  installed  AFMIS’s  at  Navy  shore 
activities;  and  develop  an  information  guide  on  AFMIS’s  for  Comptrollers.  The 
guide  is  to  be  used  in  the  Practical  Comptrollership  course  and  Financial 
Management  in  the  Armed  Forces  course  at  the  Navy  Post  Graduate  School. 
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D.  SCOPE  OF  RESEARCH 

The  thesis  will  provide  information  as  to  what  should  be  expected  from  a 
Navy  shore  command’s  AFMIS  in  addition  to  addressing  the  following  research 
questions: 

•  Do  instructions/directives  exist  for  providing  guidance  to  Navy  shore 
activity  Comptroller’s,  in  the  development  of  a  local  AFMIS? 

«  Is  there  a  need  for  further/improved  guidance  to  be  provided  by  the  Navy 
Comptroller  in  regard  to  Navy  shore  activity  Comptroller’s  AFMIS? 

•  What  AFMIS’s  are  currently  in  place  at  Navy  shore  activities,  and,  what  are 
their  features? 

•  How  were  the  AFMIS’s  developed? 

•  Are  there  RMS  activities  AFMIS’s  similarities,  and  if  so,  how  did  these 
similarities  come  to  be? 

•  What  features  should  be  incorporated  into  a  Navy  shore  activity  AFMIS? 

•  Should  Navy  shore  activity  AFMIS’s  be  compatible  with  other  activities? 

Navy  Comptrollers  are  tasked  with  a  significant  number  of  administrative 
requirements,  of  which  many  could  be  automated.  It  is  not  the  intent  of  this 
thesis  to  address  all  areas  in  a  comptroller  department  that  lend  themselves  to 
automation. 

E.  RESEARCH  APPROACH 

The  research  for  this  thesis  was  conducted  in  two  phases.  The  first  phase 
was  to  determine  what  financial  information  should  be  reviewed  by  RMS 
activities  management.  This  phase  of  the  research  entailed  a  thorough  review  of 
pertinent  publications,  and  establishing  a  liaison  with  several  key  individuals  in 
the  Navy  Comptroller  Organization.  Initially,  the  task  was  to  determine  what 
the  typical  Comptroller  at  a  Navy  shore  activity  should  have  in  his/her  AFMIS. 
Information  was  obtained  via  interviews  from  the  following  commands: 
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•  Commander,  Navy  Accounting  and  Finance  Center,  Washington,  D.C. 
(NAFC) 

•  Commander,  Naval  Surface  Force,  U.  S.  Pacific  Fleet  (COMNAVSURFPAC) 

•  Commander,  Fleet  Accounting  and  Disbursing  Center,  Atlantic  (FADCLANT) 

•  Commander,  Fleet  Accounting  and  Disbursing  Center,  Pacific  (FADCPAC) 

•  Naval  Electronics  Command,  San  Diego 

Once  it  was  determined  as  to  what  the  AFMIS  should  consist  of,  it  was 
necessary  to  obtain  a  sound  understanding  of  the  IDA  system.  Two  intended 
features  of  IDA  were  to  provide  an  AFMIS  through  a  fourth  generation  language 
report  generator.  And,  EDA  was  to  evolve  into  an  on-line  processing  system,  in 
place  of  the  current  batch  oriented  processing  system  [Ref.  3:p.  15].  Information 
on  IDA  was  obtained  from  the  Requirements  and  Specification  documents  for  the 
IDA  system  and  via  interviews  with  key  NAFC  personnel  that  were  involved  with 
the  development  of  IDA. 

The  second  phase  entailed  visiting  selected  RMS  activities  to  address  the 
research  questions.  Five  RMS  activities  were  reviewed. 

The  field  research  consisted  of  independent  interviews  with  the 
Comptroller,  Budgeting  Supervisor,  and  the  Accounting  Supervisor  at  each 
activity.  The  intentions  of  the  interviews  where  four  fold: 

•  Determine  what  automated  FMIS  is  currently  in  place. 

•  Determine  the  hardware  and  software  configuration  currently  in  place. 

•  Determine  their  methodology  as  to  how  they  developed  their  current 
system. 

•  Determine  what  guidance  was  available  to  assist  shore  RMS  activities  in  the 
development  effort  of  an  AFMIS. 
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The  interview  process  was  a  semi-structured  process.  The  interviews  entailed 
using  a  predesigned  interview  form  to  ensure  that  all  research  questions  were 
addressed  in  a  manner  that  they  could  be  compared  between  the  different  RMS 
activities  [Ref.  4:p.  111]. 

F.  THESIS  FORMAT 

The  structure  of  this  thesis  consists  of  two  primary  section"  Chapters  1 
through  4  and  Appendix  A  address  the  research  methodology,  what  attributes  an 
AFMIS  should  have,  findings,  conclusions,  and  the  recommended  financial 
management  information  system  charts/reports,  respectively.  Appendix  B  is  a 
supplemental  section  to  the  Practical  Comptrollership  Course  and  Financial 
Management  of  the  Armed  Forces  Student  Textbook.  It  provides  both 
background  and  guidance  for  comptrollers  that  are  considering  the  automation  of 
their  FMIS’s. 
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II.  MANAGEMENT  INFORMATION 


A.  INFORMATION  NEEDS 

Without  having  the  right  information  at  the  right  time,  a  manager  is 
unable  to  carry  out  his/her  responsibilities  effectively.  Information  must  be  "the" 
information  that  a  manager  needs  for  the  particular  decision  making  process  that 
he/she  is  encountering.  And,  the  information  must  be  timely.  Timeliness  is 
crucial,  receiving  the  information  when  there  is  not  adequate  time  for  the 
manager  to  take  advantage  of  a  situation,  or  to  correct  a  problem  is 
unacceptable. 

In  any  given  situation,  managers  have  different  ideas  as  to  what  information 
is  needed,  and  when.  The  variances  stem  from  some  managers  having  a  better 
feel  for  a  particular  situation,  or  maybe  having  a  better  understanding  as  to  what 
information  is  most  relevant.  The  level  of  experience  of  the  manager  will  also 
impact  the  managers  information  requirements.  Depending  on  the  level  of 
diversity  in  the  organization  and  the  dynamics  of  the  business  routine, 
information  requirements  could  range  from  a  very  stable  (a  very  systematic  and 
well  established  routine),  to  a  very  dynamic  organization  that  has  continually 
changing  information  requirements. 

Management  has  seven  types  of  information  requirements:  [Ref.  5:pp.  32- 
34] 

1)  Comfort  information:  information  that  will  tell  a  Comptroller  if  the 
organization’s  performance  is  acceptably  close  to  planned  performance. 

2)  Status  information:  information  that  helps  managers  to  monitor  projects 
or  resolution  of  problems.  For  example,  tracking  the  obligation  rate  in 
preparation  for  the  Mid-Year  Review. 
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3)  Warning  information:  information  that  tells  management  that  a  problem 
might  be  encountered.  For  example,  information  that  shows  higher  then 
usual  overtime  usage,  or  exceeding  the  projected  obligation  rate. 

4)  Planning  information:  information  that  helps  an  organization  to  determine 
what  the  objectives  should  be  and  how  to  achieve  them.  For  example,  in  the 
budgeting  process,  the  information  that  is  gathered  over  the  previous  fiscal 
year,  current  fiscal  year,  and  proposed  budget  requests  from  the  various  cost 
centers  would  be  planning  information. 

5)  Internal  Operations  information:  indicators  of  internal  organization 
performance  compared  to  expectations 

6)  External  Intelligence  information:  information  provided  from  other  sources 
outside  an  organization.  This  could  be  as  formal  as  a  Navcompt  2168-1 
Resource  Authorization  document,  or  unofficial  as  a  call  on  the  telephone 
giving  a  command  advance  notification  that  there  is  a  change  in  a  mission 
area  that  will  impact  its  financial  projections. 

7)  Externally  Distributed  information:  information  that  is  being  provided  to 
interested  parties  outside  an  organization.  For  example,  the  Type  Commander 
(TYCOM)  reviews  an  activity’s  financial  status  based  upon  the  information 
provided  by  the  FIPC. 

These  seven  types  of  information  might  be  similar  in  some  situations,  but 
different  in  others.  Information  is  generated  to  meet  several  different 
management  needs.  For  the  most  part  these  information  requirements  are 
predictable,  but  must  be  flexible  to  meet  the  current  situation. 


B.  COMPTROLLER  MANAGEMENT  INFORMATION  REQUIREMENTS 

When  trying  to  identify  the  management  information  that  is  required  to 
support  a  shore  RMS  activity,  three  questions  need  to  be  answered:  1)  What 
information  should  be  reported  to  the  users  (i.e.,  Commanding  Officer,  Executive 
Officer,  Department  Heads,  and  Comptroller)  so  that  they  can  effectively  execute 
the  responsibilities  of  their  office?  2)  How  should  the  information  be 
presented?  The  method  of  presentation  can  directly  affect  how  management  will 
interpret  the  information,  and  the  amount  of  effort  required  in  reviewing  the 
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information.  3)  How  often  should  the  information  be  presented?  Should 
management  review  every  report  on  a  weekly  basis?  Or,  should  they  review  only 
selected  reports  on  a  periodic  basis.  Should  exception  reporting  be  used?  The 
latter  two  questions  are  addressed  first,  followed  by  the  minimum  management 
information  that  is  required  in  an  AFMIS. 

1.  How  the  Information  Should  be  Presented 

Navy  RMS  activity  financial  managers  are  faced  with  the  challenge  of 
keeping  abreast  of  all  financial  accounts,  appropriations,  and  special  interest 
items.  They  must  be  able  to  review  these  various  areas  in  the  most  efficient 
manner  possible.  The  trend  in  the  commercial  sector  has  been  towards  the  use 
of  graphical  presentations  in  reviewing  management  information.  In  1986,  67 
percent  of  all  reviewed  MIS’s  used  computer  graphics.  Graphics,  if  presented 
properly,  have  the  ability  to  depict  trends  more  clearly  to  management  compared 
with  the  same  information  that  is  displayed  in  a  column  format  in  a  report.  [Ref. 
7:p.  61] 

2.  How  Often  the  Information  Should  be  Presented 

Management  does  not  have  the  need,  or  is  capable  of,  reviewing  every 
report  that  is  generated  every  day.  There  are  certain  areas  of  the  operation  that 
requires  management’s  attention  on  a  daily  basis,  but  there  are  other  areas  that 
require  only  occasional  review.  An  automated  management  information  system 
should  help  management  in  deciding  what  reports  should  be  reviewed  at  any 
given  time  [Ref.  8:p.  19].  Managerial  reports  fall  into  three  report  generation 
frequency  categories:  1)  routinely  scheduled  reports;  2)  reports  by  exception;  3) 
reports  provided  upon  request.  Each  are  discussed  below. 


a.  Routinely  scheduled  reports 

If  the  reports  are  for  satisfying  comfort  information  requirements, 
then  the  reports  should  be  generated  on  a  routine,  periodic  basis.  An  example  of 
this  type  of  report  would  be  the  Status  of  Funds  report  that  would  be  presented 
to  the  Commanding  Officer  on  a  weekly  basis. 

b.  Reports  By  Exception 

If  the  report  is  for  providing  warning  information,  then  the  report 
might  be  more  appropriate  on  an  exception  basis.  An  example  of  this  would  be 
the  monitoring  of  the  use  of  overtime.  If  the  planned  overtime  budget  is 
exceeded  by  a  certain  percent,  the  report  is  automatically  generated  for  the 
Comptrollers  review.  This  form  of  exception  reporting  also  works  well  with 
monitoring  cost  center  optar  balances  and  accounts  that  have  special  restrictions. 

c.  Reports  Generated  Upon  Request 

Reports  in  this  category  would  be  trend  analysis  reports.  These 
reports  could  be  tailored  to  meet  the  planning  information  requirements  for 
budget  preparations,  or  "what-iT  scenario’s. 

3.  Automated  Management  Information  System  Reports 

The  Comptroller’s  AFMIS  needs  to  meet  the  following  information 
requirements: 

•  Replicate  the  financial  summary  data  that  the  major  claimant  is  reviewing. 

A  Comptroller  can  not  accurately  respond  to  inquiries  made  by  the  mqjor 
claimant  involving  the  financial  status  of  the  command  without  being  aware 
of  what  the  mqjor/sub  claimant  is  reviewing.  [Ref.  8:p.  19] 

•  Generate  summary  charts  for  presentation  to  the  Commanding  Officer, 
Executive  Officer,  and  department  heads.  These  graphs  should  provide 
comfort  and/or  warning  information.  These  charts/graphs  should  depict 
trends  over  a  period  of  time  as  well  as  compare  actual  performance  against 
the  planned  budget. 
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•  Generate  summary  information  graphs  of  high  interest  or  sensitive  areas. 
This  would  encompass  financial  accounts  with  ceilings  (a  maximum  imposed 
amount  to  be  spent  in  a  given  area)  or  floors  (accounts  that  are  required  to 
have  a  minimum  amount  of  funds  expended  in  them).  This  would  also 
include  congressionally  sensitive  items  such  as  interest  payments  and 
outstanding  travel  advances. 

•  Generate  summary  charts  for  monitoring  the  internal  operation  of  the 
Comptroller  department.  Management  reports  are  needed  to  evaluate  the 
performance  and  effectiveness  of  the  employees/department  as  well  as 
identifying  weaknesses. 

The  frequency  and  distribution  of  these  various  types  of  management 
graphs/reports  would  vary  for  each  command.  The  following  management 
information  reports  are  considered  to  be  the  minimum  reports  for  a  shore 
activities  AFMIS  [Ref.  l:p.  D98,  6:pp.  9-10,  8:pp.  19-20]. 
cl  Undelivered  Orders  Reports 

Undelivered  Orders  (UDO’s)  represent  capital  tied  up  into  goods 
or  services  not  yet  received  [Ref.  l:p.  B24].  There  are  a  several  reasons  to 
monitor  UDO’s.  First,  in  the  event  of  a  funding  shortfall,  UDO’s  could  possibly 
be  cancelled  and  the  funds  recouped.  Second,  an  order  may  have  been  cancelled 
and  the  resulting  funding  credit  not  reflected  in  the  IDA  system,  therefore  a 
possible  source  of  funds.  Finally,  major/sub  claimants  monitor  subordinate 
commands  UDO’s. 

UDO’s  should  be  monitored  by  both  dollar  value  (Appendix  A 
Figure  1)  and  by  quantity  (Appendix  A  Figure  2).  A  few  high  value  UDO’s  could 
inappropriately  skew  the  charts. 

b.  Unmatched  Expenditures  Reports 

Unmatched  expenditures  are  discrepancies  between  the 
information  in  IDA,  on  an  obligation  document,  and  the  billing  documents 
information.  These  discrepancies  arise  due  to  data  entry  errors  or  prices 


changes/variances  between  the  obligation  document  and  the  actual  price  charged 
on  the  billing  document. 

Unmatched  expenditures  require  the  attention  of  a  Comptroller 
for  two  reasons.  First,  with  each  unmatched  expenditure  there  exists  the 
possibility  that  the  obligated  amount  in  the  IDA  accounting  system  is 
understated  (the  goods  or  services  cost  more  then  the  posted  amount),  this  could 
contribute  to  an  over  obligated  status  (violation  of  Title  31  section  1517).  The 
reverse  also  holds  true,  in  that,  if  there  is  a  substantial  amount  of  overstated 
obligations,  then  there  are  funds  available  in  the  system  that  a  Comptroller  is 
unaware  of. 

Second,  an  effort  on  the  part  of  the  accounting  staff  is  dedicated 
to  resolving  unmatched  expenditures.  Monitoring  unmatched  expenditures  gives 
management  a  tool  to  review  how  well  the  staff  is  performing  in  respect  to 
resolving  unmatched  expenditures. 

Unmatched  expenditures  should  be  tracked  by  both  dollar  value 
(Appendix  A  Figure  3)  and  quantity  (Appendix  A  Figure  4). 
c.  Obligation  and  Commitment  Reports 

A  commitment  is  an  administrative  process  of  reserving  funds  for 
a  future  obligation.  An  obligation  is  an  order  placed  or  a  contract  awarded.  An 
obligation  is  an  official  reservation  of  funds.  Both  commitments  and  obligations 
directly  affect  the  future  balance  of  funds.  It  is  necessary  to  monitor  both 
obligation  and  commitment  level  to  ensure  that  a  Title  31  violation  is  not 
incurred.  The  following  five  reports  assists  the  Navy  shore  command’s 
management  in  monitoring  commitments  and  obligations  at  various  levels  of  the 
organization.  [Ref.  l:p.  B15J 
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(1)  Commitments  Planned  vs.  Actual  Report.  Monitoring  available 
funds  (Total  Obligated  Authority  less  Gross  Adjusted  Obligations  equals  Available 
Balance)  requires  that  both  commitments  and  obligations  be  reviewed  together. 
This  will  give  management  the  information  needed  to  evaluate  the  current 
funding  environment  within  the  command  (Appendix  A  Figure  5). 

(2)  Obligations  Planned  vs.  Actual  Report.  Obligations  are  the 
official  reservation  of  funds  based  upon  placing  an  order  or  awarding  a  contract. 
This  report  is  reviewed  by  the  major  claimant,  via  IDA,  to  evaluate  an  activity’s 
obligation  rate  compared  to  its  budgeted  rate  (Appendix  A  Figure  6). 

(3)  Base  Operating  Expense  Report.  Next  to  Civilian  payroll 
expenses,  base  operating  costs  are  traditionally  the  next  highest  expense 
category.  The  Base  Operating  Expense  Report  should  be  a  summary  report  of  all 
base  operating  expense  accounts  (Appendix  A  Figure  7). 

(4)  Cost  Center  Operating  Target  Report.  Commanding  Officers 
allocate  funds  to  cost  centers  for  the  purpose  of  conducting  their  daily  business. 
The  Cost  Center  OPTAR  Report  serves  as  a  routine  management  tool  for  the 
cost  centers,  and  as  an  exception  report  to  the  Comptroller  if  the  cost  center 
exceeds  the  parameters  imposed  within  the  report  (Appendix  A  Figure  8). 

(5)  Reimbursable  Execution  Report.  The  majority  of  shore 
activities  require  the  assistance  of  other  commands/organizations  to  perform 
services.  This  is  often  done  on  a  reimbursable  means.  The  requesting  command 
submits  a  work/service  request  to  the  providing  organization.  Within  this  work 
request  there  is  an  agreed  dollar  amount  that  it  will  cost  for  the  service.  The 
amount  of  the  work  request  is  obligated  upon  submission  to  the  servicing 
activity.  Failure  to  monitor  reimbursable  accounts  could  lead  to  either  an 
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account  with  excess  funds,  or  an  over  obligated  account  at  the  end  of  the  fiscal 
year. 

The  Reimbursable  Execution  Report  (Appendix  A  Figure  9)  monitors  the 
actual  reimbursable  execution,  compared  to  the  planned.  This  report  would  be 
generated  on  an  exception  basis  (the  actual  cost  of  the  reimbursable  work  falls 
outside  the  parameters  of  the  budgeted  costs). 
d.  Civilian  Pay  Reports 

The  following  four  civilian  personnel  reports  are  recommended: 
Management  to  Payroll  Planned  vs.  Actual,  cumulative;  Management  to  Payroll 
Planned  vs.  Actual,  by  pay  period;  Overtime  Dollars  Planned  vs.  Actual;  and  Civil 
Service  Grade  Creep.  [Ref.  8:p.  20] 

(1)  Management  to  Payroll  Reports. 

If  a  civilian  pay  account  becomes  over  obligated,  corrective 
action  can  involve  several  different  initiatives,  depending  upon  the  severity  of  the 
over  obligation  and  how  early  the  problem  was  identified.  The  solutions  range 
from  hiring  freezes,  laying  off  temporary  employees,  elimination  of  overtime,  and 
possibly  furlough. 

The  civilian  payroll  accounts  should  be  monitored,  at  a 
minimum,  on  an  exception  basis.  The  accounts  should  be  monitored  on  both  a 
cumulative  (Appendix  A  Figure  10)  and  pay  period  basis  (Appen  A  Figure  11). 

(2)  Civilian  Overtime  Dollars  Report.  If  civilian  overtime  dollars 
are  budgeted  out  to  the  cost  centers,  then  this  report  would  be  appropriate  for 
review  at  the  cost  center  level  on  a  periodic  basis  (Appendix  A  Figure  12).  If  the 
overtime  dollars  are  centrally  managed,  then  the  reports  should  be  generated  for 
the  shore  command’s  management  to  review. 
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(3)  Civilian  Personnel  Grade  Creep  Report.  By  monitoring  the 
overall  average  civil  service  grades  within  the  organization,  it  is  possible  to 
evaluate  the  hiring  practices  of  the  organization.  The  average  civil  service  grade 
directly  affects  the  overall  cost  within  the  civilian  pay  account.  This  report 
would  be  appropriate  for  review  on  a  periodic  basis  (Appendix  A  Figure  13). 
e  Higher  Authority  Interest  Item  Reports 

Due  to  Congressional  interest  in  the  Navy’s  budgeting  process, 
there  are  financial  accounts  that  receive  closer  then  normal  scrutiny  from  the 
major/sub  claimant.  These  high  interest  areas  warrant  incorporation  into  the 
AFMIS.  Interest  payments,  as  a  result  of  not  meeting  the  Prompt  Payment  Act 
provisions,  (Appendix  A  Figure  14)  and  Outstanding  Travel  Advances  (Appendix  A 
Figure  15)  are  examples  of  currently  highly  visible  accounts.  [Ref.  l:p.  D98] 

C.  COMPATIBILITY  OF  FINANCIAL  MANAGEMENT  INFORMATION  SYSTEMS 
Compatibility  is  a  critical  aspect  of  any  automated  information  system. 

When  an  information  system  involves  more  then  one  computer  system,  the 
question  of  compatibility  arises.  Compatibility  of  computer  systems  have  two 
areas  of  focus;  compatibility  of  hardware  (computers)  and  compatibility  of 
software. 

Micro-computers  are  in  use  at  both  the  cost  center  level  and  the 
comptroller  department  level.  If  an  AFMIS  system  is  going  to  encompass  these 
two  activity  levels,  then  the  hardware  configuration  must  be  compatible.  A 
comptroller’s  AFMIS  should  have  the  capability  of  receiving  financial  data  from 
the  cost  centers  (electronically)  and  the  cost  centers  should  be  able  to  receive 
data  from  a  comptroller’s  AFMIS.  Without  hardware  compatibility,  the  electronic 
transfer  of  data  would  not  be  possible. 
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RMS  activity  AFMIS’s  should  be  compatible  with  the  Navy ’s  official 
accounting  system  (IDA).  An  RMS  activity  AFM3S  should  have  the  capability  to 
electronically  receive  (download  information)  and  transmit  (upload  information) 
data  between  the  two  systems.  Without  compatibility,  the  information  will  have 
to  be  manually  transferred  from  one  system  to  the  other. 

As  with  hardware,  software  within  a  AFMIS  must  also  be  compatible.  If 
information  that  is  entered  in  one  part  of  the  AFMIS  is  intended  to  be  used  in 
another  part  of  the  AFMIS,  then  the  different  software  components  that  share 
this  data  must  be  compatible  (data  must  be  stored  and  retrieved  in  a  format  that 
is  recognizable  by  the  two  systems).  Without  direct  compatibility,  an  additional 
program  might  be  required  to  modify  the  format  of  the  data  from  one  program 
to  the  other  program  so  that  the  data  can  be  used.  Or  worst  case,  the  data  will 
not  be  transferable  due  to  the  lack  of  compatibility. 
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III.  RMS  ACTIVITY  FINANCIAL  MANAGEMENT  INFORMATION  SYSTEM’S 

A.  OVERVIEW  OF  FINDINGS 

While  conducting  interviews  at  the  RMS  activities,  the  following 
observations  were  made:  There  is  very  little  consistency  between  the  comptroller 
departments  AFMIS’s;  There  is  no  guidance  available  to  the  RMS  activities  as  to 
how  to  approach  the  development  of  a  AFMIS;  Of  the  five  RMS  activities  that 
were  reviewed,  there  is  not  a  single  application  program  that  was  utilized  in 
more  then  one  activity;  The  methodology  as  to  how  comptrollers  generate  their 
management  reports  are  all  different;  and,  the  use  of  micro-computers  varied 
considerably  from  each  command. 

B.  GUIDANCE  ON  THE  DEVELOPMENT  OF  AUTOMATED  FINANCIAL 
MANAGEMENT  INFORMATION  SYSTEM’S 

Based  upon  a  literature  search  and  the  interviews  conducted,  it  is  the 
opinion  of  this  author  that  there  has  been  no  guidance  provided  to  RMS  activity 
comptrollers  for  the  purpose  of  automating  a  local  FMIS. 

C.  CURRENT  IN-PLACE  FINANCIAL  MANAGEMENT  INFORMATION 
SYSTEM’S  AT  RMS  ACTIVITIES 

1.  Features  of  In-place  Automated  Financial  Management  Information 
System’s  (AFMIS) 

The  features  of  the  various  AFMIS’s  vary  greatly.  There  is  very  little 
commonality  amongst  the  Navy  shore  activities.  The  features  of  the  different 
systems  include: 
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•  Electronic  transfer  of  either  accounting  data  or  report  information  from  IDA 
to  the  RMS  activities  AFMIS.  Of  the  five  RMS  activities,  one  activity  is 
downloading  information  (electronic  transfer  of  data  from  IDA  to  the 
activities  AFMIS).  The  other  four  RMS  activities  use  IDA  printouts  to 
extract  the  relevant  data  for  review. 

•  Automated  report  generation.  Automated  report  generation  varies  at  the 
five  commands.  Four  of  the  five  commands  use  micro-computers  to 
manipulate  and  display  data.  The  one  activity  that  does  not  use  the  micro¬ 
computer  relies  upon  manual  ledgers  and  the  IDA  printed  reports. 

•  Ability  to  generate  reports  by  exception.  None  of  the  RMS  activities  use  a 
report  by  exception  reporting  methodology.  All  reports  are  generated  upon 
request. 

•  Use  of  graphs  and  charts  to  display  management  reports.  Two  of  the  five 
RMS  activities  use  graphical  printouts  to  present  their  information.  The 
other  three  activities  present  their  information  in  spreadsheet  format. 

•  Data  sharing  among  micro-computer  users.  Of  the  five  systems  reviewed, 
one  RMS  activity  has  the  capability  to  share  information  with  other  users. 
All  other  systems  are  application  and  user  independent. 

•  Exportation  of  AFMIS  to  cost  centers  for  use.  One  activity  has  exported 
their  AFMIS  out  to  their  cost  centers  for  use. 

•  Ability  to  upload  data  to  IDA  from  the  local  AFMIS.  None  of  the  RMS 
activities  have  this  capability.  Presently  two  of  the  activities  are  pursuing 
this  capability  (independent  of  each  other). 

2.  What  Are  The  Similarities  Of  The  Various  Automated  FMIS’s 

Presently  there  is  no  standardization  among  any  of  the  reviewed 
activities  for  gathering,  manipulating,  and  reviewing  automated  financial 
management  information.  This  has  resulted  in  very  few  similarities.  In  the 
absence  of  guidance,  all  reviewed  activities  are  determining  and  creating  their 
own  versions  of  an  automated  FMIS.  The  degree  of  automation  in  the  FMIS’s  at 
the  comptroller  department  level  ranged  from  very  little,  to  activities  that  use 
micro-computers  on  a  routine  basis  for  the  purpose  of  information  gathering  and 
report  generation. 
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All  of  the  activities  reviewed  use  the  same  basic  financial  information 
on  a  routine  basis.  But,  there  is  no  common  method  used  for  extracting  the 
data  and  preparing  it  for  presentation  to  management. 

The  software  used  on  the  micro-computers  in  the  Comptroller 
Departments  are  also  different.  Both  In-house  developed  software,  where  the 
command’s  computer  programmers  write  a  special  designed  program  for  that 
command  (at  one  RMS  activity),  to  the  use  of  various  Off-the-shelf  software 
packages,  such  as  Lotus  1-2-3  and  dBase  m,  were  used.  For  those  activities  that 
used  the  "off-the-shelf  software,  the  accountants  and  budgeteers  in  the 
comptroller  department  developed  their  own  applications  (working  versions  of  the 
program). 

3.  How  The  Automated  FMIS’s  Were  Developed 

While  conducting  the  interviews,  at  the  RMS  activities,  the  following 
observation  was:  Comptroller  Department  personnel  have  very  little,  if  any, 
understanding  as  to  how  to  go  about  developing  an  automated  FMIS.  The 
automated  systems  that  are  currently  in-place  are  piece-meal.  The  development 
is  piece-meal  in  that  an  employee  sees  a  need  and  pursues  the  automation  of 
that  particular  report  for  a  given  financial  area.  More  often  then  not,  other 
potential  requirements  that  could  also  be  met  by  these  efforts  are  not  taken  into 
account. 

This  approach  to  automating  a  FMIS  results  in  several  applications 
that  possibly  are  redundant  in  nature,  or,  are  not  compatible  with  each  other. 
Also,  with  this  independent  development  effort,  a  problem  arises  as  to  who 
maintains  the  programs  that  were  developed,  and  how  will  they  be  maintained. 
Modifications/changes  to  a  program  that  are  independently  developed  by  a  user 
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are  very  difficult  and  costly.  Individuals  that  develop  a  program  for  their  own 
use  in  an  office  environment  traditionally  do  not  document  how  the  program 
operates.  The  user  develops  the  program  while  they  are  working  at  their  desk, 
and  once  the  program  meets  their  needs,  they  start  using  it  without  thinking  of 
documenting  what  they  have  done.  This  was  the  case  at  the  five  RMS  activities 
reviewed. 

4.  Problems  Encountered  in  the  Development  of  AFMIS’s 

During  the  development  of  the  AFMIS’s  at  the  activities  reviewed, 
several  problems  were  encountered.  The  following  "lessons  learned"  were 
vocalized  during  the  interview  process: 

•  The  developers  failed  to  identify  what  computer  systems  were  available  to 
the  users.  The  developed  application  ended  up  not  being  compatible  in  all 
cost  centers,  which  required  the  cost  centers  to  procure  additional 
equipment. 

•  Users  where  not  involved  in  the  development  process.  This  lack  of 
involvement  resulted  in  flawed  requirement  specifications. 

•  The  developed  application  required  the  cost  centers  to  have  a  copy  of  a 
particular  software  package  to  use  the  AFMIS.  Several  cost  centers  did  not 
have  the  required  software  package,  and,  did  not  have  the  funding  to 
procure  the  required  package. 

•  The  developers  of  the  application  assumed  that  the  users  were  familiar  with 
computers  and  the  selected  "Off-the-ShelF  software.  This  lead  to  the 
development  of  an  application  that  was  too  complex  for  the  average  user  to 
use. 

•  Failure  to  field  test  the  system  prior  to  full  implementation  resulted  in  an 
unreliable  product  that  users  refused  to  use. 

•  Lack  of  scheduling  formal  training  resulted  in  the  implementation  of  the 
AFMIS  with  little  support  from  the  users.  It  was  assumed  that  the  users 
would  be  interested  enough  in  the  new  AFMIS  to  obtain  the  training 
required  for  the  new  system,  on  their  own. 

•  Desk  top  guides  were  not  developed  for  the  users.  This  greatly  hindered 
the  implementation  process  and  user  acceptance. 


•  Backup  and  recovery  procedures  where  not  adequately  tested  prior  to 
implementation.  This  resulted  in  a  cost  center  having  to  re-enter  a 
significant  amount  of  data  into  the  AFMIS. 

•  Use  of  the  developed  AFMIS  at  the  cost  centers  was  not  mandatory. 
Therefore,  the  cost  centers  refused  to  convert  over  from  their  old/familiar, 
system  to  the  new  system. 

•  There  was  no  documentation  for  the  AFMIS.  When  the  developer 
transferred,  there  was  no  one  knowledgeable  within  the  organization  to 
maintain  the  software. 

5.  Compatibility  of  AFMIS's 

Compatibility  of  in-place  AFMIS*  were  reviewed  from  three 

prospectives.  First,  from  the  view  point  of  compatibility  within  the  Comptroller 

department.  Second,  the  compatibility  between  different  RMS  activities.  And 

third,  the  compatibility  between  the  RMS  activities  AFMIS  and  IDA. 

cl  Compatibility  within  the  Comptroller  Department 

The  computer  hardware  within  the  reviewed  activities  where 

found  to  be  compatible.  And,  the  software  in  use  (primarily  Lotus  1-2-3  and 

Dbase  HI)  by  the  RMS  activities  were  also  found  to  be  compatible,  in  that  the 

programs  are  able  to  retrieve  and  store  data  in  a  format  that  can  be  recognized 

between  the  programs. 

However,  the  compatibility  of  the  applications  (application  being 
the  adaptation  of  the  commercial  software  to  meet  their  needs)  that  are  in  use, 
are  developed  with  little,  if  no  consideration  of  other  potential,  or  currently 
existing,  applications.  As  a  result,  the  applications  are  not  compatible  with  each 
other.  The  applications  are  not  able  to  share  or  transfer  data  electronically  to 
other  applications. 


6.  Compatibility  Between  RMS  Activity  AFMIS’s 


There  is  no  apparent  need  for  compatibility  between  RMS  activity 
AFMIS’s.  RMS  activities  do  not  share  any  financial  data  between  them. 
Therefore  the  need  for  compatibility  does  not  exist. 

c.  Compatibility  Between  RMS  Activity  AFMIS’s  and  FIPC 

The  determination  of  compatibility  between  RMS  activity  AFMIS’s 
and  FIPC  is  beyond  the  scope  of  this  thesis.  There  is  a  need  for  the 
compatibility  between  FIPC  and  the  RMS  activities.  Presently,  there  exists  the 
capability  for  FIPC’s  to  download  data  to  RMS  activities.  Presently  none  of  the 
reviewed  RMS  activities  have  the  capability  to  upload  to  the  FIPC  system.  Two 
of  the  five  RMS  activities  are  in  the  process  of  trying  to  gain  this  capability. 
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IV.  CONCLUSIONS 


A.  INTRODUCTION 

The  conclusions  offered  in  this  chapter  are  based  upon  the  readings, 
interviews,  and  observations  made  during  the  research  conducted  in  the  course  of 
this  thesis. 

B.  CONCLUSIONS 

For  RMS  activities  to  be  able  to  effectively  manage  their  financial 
resources,  it  is  necessary  for  the  activity  to  have  a  local  financial  management 
information  system  (manual  or  automated)  to  supplement  IDA  reporting 
capability.  Without  exception,  the  reviewed  activities  recognize  the  importance  of 
a  local  financial  management  information  system  and  have  one  in  place. 

The  IDA  accounting  system  is  not  setup  to  provide  the  required  up-to-date 
information  in  the  format  that  the  RMS  activity  managers  require.  The 
consensus  among  the  RMS  activities  is  that  IDA’s  current  report  generation 
capability  is  inflexible  and  difficult  to  interpret. 

Throughout  the  discussions  with  comptroller  department  personnel  it  is 
recognized  that  micro-computers  can  help  them  in  their  daily  routine  but  are  at 
a  loss  as  to  how  to  go  about  it.  RMS  activities  need  to  take  greater  advantage  of 
their  available  micro-computers.  Micro-computers  can  enhance  the  productivity 
of  the  comptroller’s  department  greatly.  Computers  take  about  20  percent  of  the 
manpower  time  that  manual  calculations  do  [Ref.  9:p.  65]. 

With  the  RMS  activity  Comptrollers  recognizing  the  need  for  automated 
financial  information  systems,  the  Comptrollers  have  been  encouraging  their 


accountants  and  budgeteers  to  automate  applications  within  their  functional 
areas.  The  problem  with  this  approach  is  that  the  staff  does  not  have  an 
adequate  understanding  as  to  how  to  approach  the  development  of  an  AFMIS. 

The  applications  that  are  developed  are  stand  alone  applications  with  very  little 
consideration  of  other  possible  applications. 

C.  RECOMMENDATIONS 

RMS  activities  have  two  basic,  but  common,  features.  First,  the  information 
requirements  at  RMS  activities  are  similar.  Second,  with  micro-computers  being 
readily  available  at  the  RMS  activities,  the  focus  of  an  AFMIS  should  be  towards 
taking  advantage  of  theses  computers.  The  two  recommendations  made,  take 
into  account  that  EDA  will  adventually  be  replaced  by  a  DoD  standard  accounting 
system. 

These  recommendations  can  be  accomplished  through  the  Navy 
Postgraduate  School  (NPS)  Thesis  process.  If  the  NPS  is  used  to  accomplish 
these  recommendations,  it  should  be  sponsored  by  the  appropriate  organization 
level  that  is  able  to  promote  and  distribute  the  final  product. 

1.  Development  of  a  Generic  Automated  Financial  Management 
Information  System 

To  minimize  the  current  duplication  of  effort  in  developing  AFMIS’s  at 
the  local  activity  level,  a  generic  AFMIS  should  be  developed.  With  the  majority 
of  the  information  requirements  being  the  same  at  all  shore  activities,  a  generic 
AFMIS  could  be  developed  to  support  these  common  needs.  The  following 
features  should  be  considered  during  the  development  of  the  generic  AFMIS. 

•  The  use  of  "Off-the  Shelf  software  in  this  development  effort  could  greatly 

reduce  the  development  time  and  effort. 


•  The  generic  AFMIS  should  be  developed  with  modularity  in  mind.  The 
shore  activity  should  not  be  required  to  implement  the  complete  AFMIS  to 
take  advantage  of  particular  features  of  the  AFMIS  that  the  activity  is 
interested  in. 

•  The  generic  AFMIS  should  include  a  report  generation  capability  so  that 
the  individual  activities  can  customize  their  reports  to  meet  their  needs. 

•  The  generic  AFMIS  should  include  a  recommended  training  plan  for 
activities  to  follow.  Recommend  the  incorporation  of  an  on-line  tutorial  (a 
computer  program  for  training  new  users)  as  part  of  the  training  package. 

•  The  generic  AFMIS  needs  to  be  accompanied  with  a  users  guide  for  each 
type  of  intended  user.  Documentation  on  the  application  is  necessary  so 
that  modification  of  the  system  at  the  local  level  would  be  possible. 


2.  Establish  Guidance  for  RMS  Activities  to  Develop  an  AFMIS 

Presently  there  is  no  published  guidance  as  to  how  to  automate  a 
financial  information  system  at  RMS  activities.  Without  having  a  guide  to  help 
direct  the  efforts  of  the  shore  activity,  the  difficulties  encountered  by  various 
activities,  as  indicated  in  the  findings,  will  reoccur  at  other  activities. 

Without  guidance,  systems  will  continue  to  be  developed  that  are  not 
standardized  with  other  Navy  activities.  Even  though  the  activities  do  not  share 
financial  data  between  them,  reassignment  of  employees,  via  transfers,  are 
common.  With  non-standardized  AFMIS’s,  the  need  for  the  activity  to  retrain 
the  newly  arrived  employee  from  another  Navy  activity,  is  an  expense  that  could 
be  prevented. 
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APPENDIX  A  "  SAMPLE  MANAGEMENT  INFORMATION  REPORTS 
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Figure  2  Undelivered  Orders  by  Quantity 


Figure  3  Unmatched  Expenditure  by  Dollar  Value 


Figure  4  Unmatched  Expenditures  by  Quantity 
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4th  QTR 
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4th  QTR 
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4th  QTR 


Figure  9  Reimbursable  Report 
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Management  to  Payroll 


Figure  10  Management  to  Payroll,  Cumulative 
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Ray  Parioda 
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-  Report  by  Exception 
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4th  QTR 


Figure  15  Outstanding  Travel  Advances  Report 
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APPENDIX  B  *  PRACTICAL  COMPTROLLERSHIP  COURSE  AND  FINANCIAL 
MANAGEMENT  OF  THE  ARMED  FORCES  STUDENT  TEXTBOOK  SUPPLEMENT: 
AUTOMATION  OF  A  FINANCIAL  MANAGEMENT  INFORMATION  SYSTEM 


Based  upon  comments  from  students  attending  the  Practical 
ComptroUership  Course  at  the  Navy  Postgraduate  School  it  was  apparent  that 
there  were  many  misconceptions  as  to  what  an  automated  financial  management 
information  system  (AFMIS)  is,  what  it  should  be,  and  how  to  develop  one.  This 
paper  is  based  upon  a  review  of  several  Navy  shore  activities  and  their  Financial 
Management  Information  Systems  (FMIS). 

This  paper  first  addresses  what  management  information  is,  then  what  a 
AFMIS  should  provide  with  respect  to  management  information.  The  final 
chapter  discusses  how  to  approach  the  development  of  an  AFMIS. 

There  are  four  appendixes  to  this  paper.  Appendix  AA,  is  a  proposed 
check-off  list  that  a  command  could  use  during  the  initial  phases  of  developing 
an  AFMIS.  The  check-off  list  is  designed  to  assist  an  organization  in  starting  off 
in  the  right  direction  of  initiating  the  development  effort  within  their  command. 

Appendix  BB  is  a  listing  of  lesson’s  learned  by  various  shore  activities  that 
implemented  an  AFMIS.  Appendix  CC  contains  sample  management  information 
reports  that  an  AFMIS  should  provide. 
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Appendix  DD  is  a  general  discussion  on  what  a  computer  is  and  how  it 
works.  It  is  oriented  towards  those  that  have  very  little  experience  or  knowledge 


as  to  how  computers  operate.  Appendix  DD  is  not  intended  to  serve  as  an 
extensive  guide  on  computers,  there  are  various  books  on  the  market  addressing 
this  particular  topic. 
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I.  MANAGEMENT  INFORMATION 


A.  MANAGEMENT  INFORMATION  SYSTEMS 

There  is  a  difference  between  a  Management  Information  System  (MIS)  and 
an  Automated  Management  Information  System  (AMIS).  MIS  is  any  standardized 
approach  to  accumulating  data  and  adjusting/manipulating  the  data  in  a  manner 
that  is  useful  to  an  organization.  This  includes:  personnel  files;  payroll  records; 
financial  status  of  the  organization;  work  schedules;  etc. 

An  Automated  MIS  (AMIS)  is  a  computerized  system  that  accepts  input 
from  various  sources  and  manipulates  the  data  to  generate  useful  information  for 
management.  Depending  upon  the  size  of  a  requirement,  an  automated  system 
could  be  operated  on  a  computer  as  small  as  a  micro-computer  (desk  top 
computer)  or  as  large  as  a  mainframe  computer  at  a  computer  center. 

B.  COMPTROLLER  MANAGEMENT  INFORMATION  REQUIREMENTS 

When  trying  to  identify  what  management  information  is  required  to 

support  a  comptroller,  three  questions  need  to  be  answered:  1)  What 
information  needs  to  be  reported  to  the  Commanding  Officer,  Executive  Officer, 
Department  Heads,  and  the  Comptroller,  so  that  they  can  effectively  execute  the 
responsibilities  of  their  offices.  2)  How  should  the  information  be  presented. 
The  method  of  presentation  can  directly  affect  how  they  will  interpret  the 
information,  and  the  amount  of  effort  required  by  management  in  reviewing  the 
information.  3)  How  often  should  the  information  be  presented?  Should 
management  review  every  report  on  a  weekly  basis?  Or,  should  they  review  only 
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selected  reports  on  a  periodic  basis.  Should  exception  reporting  be  used?  The 
latter  two  questions  are  addressed  first,  followed  by  what  is  considered  the 
minimum  management  information  that  is  required  in  an  AFM3S. 

1.  How  the  Information  Should  be  Presented 

Management  is  required  to  be  aware  of  the  status  of  a  multitude  of 
financial  accounts,  appropriations,  and  special  interest  items.  They  must  be  able 
to  review  these  various  areas  in  the  most  efficient  manner  possible.  The  trend 
in  the  commercial  sector  has  been  towards  the  utilization  of  graphical 
presentations  in  management  information  systems.  In  1986,  sixty-seven  percent 
of  all  reviewed  MIS’s  used  computer  graphics.  Graphics,  if  presented  properly, 
have  the  ability  to  depict  trends  more  clearly  to  management,  compared  to  the 
same  information  that  is  displayed  in  a  column  format  in  a  report.  [Ref.  7:p.  61] 

2.  How  Often  the  Information  Should  be  Presented 

Management’s  time  is  a  precious  resource,  therefore,  we  want  to  focus 
their  available  time  on  the  most  relevant  information  within  the  organization. 
Management  does  not  have  the  need,  or  is  capable  of,  reviewing  every  report 
that  is  generated  every  day.  There  are  certain  areas  of  the  operation  that 
requires  management’s  attention  on  a  daily  basis,  but  there  are  other  areas  that 
require  only  occasional  review  to  ensure  that  things  are  on  track.  A 
management  information  system  should  help  management  in  deciding  what  does 
and  does  not  require  their  attention.  [Ref.  8:p.  19] 

Managerial  reports  fall  into  three  report  generation  frequency 
categories:  1)  routinely  scheduled  reports;  2)  reports  by  exception;  3)  reports 
provided  upon  request.  Each  are  discussed  below. 


a.  Routinely  scheduled  reports 

If  the  reports  are  for  providing  comfort  information  then  the 
reports  should  be  generated  on  a  routine,  periodic  basis.  An  example  of  this 
type  of  report  would  be  the  Status  of  Funds  report  that  would  be  presented  to 
the  Commanding  Officer  on  a  weekly  basis. 

b.  Reports  By  Exception 

If  the  report  is  for  highlighting  potential  problems,  then  the 
report  might  be  more  appropriate  on  an  exception  basis.  An  example  of  this 
would  be  the  monitoring  of  the  use  of  overtime.  If  the  planned  overtime  budget 
is  exceeded  by  a  certain  percent,  the  report  is  automatically  generated  for 
managements  review.  This  form  of  exception  reporting  also  works  well  with 
monitoring  the  cost  center  optar  balances  and  accounts  that  have  special 
restrictions. 

c.  Reports  Generated  Upon  Request 

The  type  of  reports  that  could  be  in  this  category  are  trend 
analysis  reports.  These  reports  could  be  tailored  to  meet  the  planning 
information  requirements  for  budget  preparations,  or  "what-iF  scenario’s. 

3.  Automated  Management  Information  System  Reports 

The  Comptroller’s  AFMIS  needs  to  meet  the  following  information 
requirements  [Ref.  8:p.  19]: 

•  Replicate  the  financial  summary  data  that  the  major /sub  claimant  is 
reviewing. 

•  Generate  summary  charts  for  presentation  to  the  Commanding  Officer, 
Executive  Officer,  and  department  heads.  These  graphs  will  provide 
comfort  and/or  warning  information. 


47 


•  Generate  summary  information  graphs  of  high  interest  or  sensitive  areas. 

•  Generate  summary  charts  for  monitoring  the  internal  operation  of  the 
Comptroller  department. 

The  frequency  and  distribution  of  these  various  types  of  management 
graphs/reports  would  vary  for  each  command.  The  following  management 
information  reports  are  considered  to  be  the  minimum  reports  of  an  AFMIS  [Kef. 
l:p.  D98,  6:pp.  9-10,  8:pp.  19-20]. 

•  Undelivered  Orders  Reports  (Appendix  CC  Figures  1  and  2) 

•  Unmatched  Expenditures  Reports  (Appendix  CC  Figures  3  and  4) 

•  Obligation  and  Commitment  Report  (Appendix  CC  Figure  5) 

•  Obligations  Planned  vs.  Actual  Report  (Appendix  CC  Figure  6) 

•  Base  Operating  Expense  Report  (Appendix  CC  Figure  7) 

•  Cost  Center  Operating  Target  Report  (Appendix  C  Figure  8) 

•  Reimbursable  Execution  Report  (Appendix  CC  Figure  9) 

•  Management  to  Payroll  Reports  (Appendix  CC  Figures  10  and  11) 

•  Civilian  Overtime  Dollars  Report  (Appendix  CC  Figure  12) 

•  Civilian  Personnel  Grade  Creep  Report  (Appendix  CC  Figure  13) 

•  Interest  Payments  Report  (Appendix  CC  Figure  14) 

•  Outstanding  Travel  Advance  (Appendix  CC  Figure  15) 

C.  COMPATIBILITY  OF  FINANCIAL  MANAGEMENT  INFORMATION  SYSTEMS 
Compatibility  is  a  critical  aspect  of  any  automated  information  system. 

When  an  information  system  involves  more  then  one  computer  system,  the 
question  of  compatibility  arises.  Compatibility  of  computer  systems  have  two 


areas  of  focus;  compatibility  of  hardware  (computers)  and  compatibility  of 
software. 

Micro-computers  are  in  use  at  both  the  cost  center  level  and  the 
comptroller  department  level.  If  an  AFMIS  system  is  going  to  encompass  these 
two  levels  of  the  organization  then  the  hardware  configuration  must  be 
compatible,  otherwise  the  sharing  of  programs  and  data  would  not  be  easily 
accomplished.  Hardware  compatibility  is  also  an  issue  between  a  Comptroller’s 
AFMIS  and  the  IDA  system. 

As  with  hardware,  software  within  an  AFMIS  must  also  be  compatible.  If 
information  that  is  entered  in  one  part  of  the  AFMIS  is  intended  to  be  used  in 
another  part  of  the  AFMIS,  then  the  different  software  components  that  share 
this  data  must  be  compatible  (data  must  be  stored  and  retrieved  in  a  format  that 
is  recognizable  by  the  two  systems).  With  out  direct  compatibility,  an  additional 
program  might  be  required  to  modify  the  format  of  the  data  from  one  program 
to  another  so  that  the  data  can  be  used.  Or  worst  case,  the  data  will  not  be 
transferable  due  to  lack  of  compatibility. 

An  organization’s  AFMIS  ideally  should  be  compatible  with  the  FIPC’s 
official  accounting  syst  *ru  An  AFMIS  should  have  the  capability  to  electronically 
receive  (download  information)  and  transmit  (upload  information)  data  between 
the  two  systems.  An  AFMIS  should  also  be  compatible  between  a  comptroller’s 
and  cost  center’s  AFMIS.  A  comptroller’s  AFMIS  should  have  the  capability  of 
receiving,  electronically,  financial  data  from  the  cost  centers  and  the  cost  centers 
should  be  able  to  receive  data  from  the  comptroller’s  AFMIS. 
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II.  HOW  TO  DEVELOP  AN  AFMIS 


A.  DISCUSSION 

The  effort  involved  in  developing  an  AFMIS  is  often  underestimated  by 
both  management  and  users.  The  investment  of  both  time  and  money  needs  to 
be  recognized  up  front,  prior  to  undertaking  the  effort  of  automating  a  FMIS. 
Without  properly  recognizing  this,  it  will  be  difficult  for  management  to 
adequately  support  the  project.  Management’s  commitment  to  the  development 
effort  and  cost  incurred  throughout  the  development  period  often  determines  the 
level  of  success  as  to  quality  of  the  completed  system  [Ref.  10:pp.  263-264]. 

1.  Development  Methodologies 

There  are  several  industry  accepted  methodologies  as  to  how  to 
approach  the  development  of  an  automated  information  system.  A  methodology 
is  a  framework  for  guiding  a  software  development  project  from  conception  to 
completion.  The  methodologies  fall  into  two  basic  categories:  System 
Development  Life  Cycle;  and  Prototyping.  [Ref.  5:pp.  603] 

The  System  Development  Life  Cycle  (SDLC)  approach  is  a  traditional 
methodology  that  has  been  extensively  used  over  the  years.  SDLC  is  a  specific 
step  by  step  process  for  developing  the  system.  A  distinctive  feature  of  this 
approach  is  that  once  the  developer  identifies  the  requirements  that  the  user 
thinks  he/she  wants,  the  software  development  team  goes  forward  with  the 
development  of  the  application.  The  user’s  involvement  with  the  SDLC 
methodology  is  limited  to  the  initial  requirements  phase  and  the  acceptance  of 
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the  product.  It  is  not  until  the  latter  part  of  the  development  effort  that  the 
user  gets  to  actually  see  what  the  end  product  is  going  to  look  like.  If  the  user 
finds  out  at  this  point  that  they  didn’t  correctly  identify  all  of  the  requirements 
that  they  wanted  in  the  system,  it  is  often  too  late,  or  too  costly,  to  change. 

The  Prototyping  methodology,  in  contrast,  assumes  that  the  user  is  not  able  to 
accurately  identify  the  requirements  of  the  system  up  front.  Prototyping  is  an 
approach  that  keeps  the  user  involved  throughout  the  development  process. 

This  approach  requires  both  the  user  and  the  developer  to  sit  down  and  review 
what  the  user  likes  and  dislikes  with  the  current  system  in  place.  From  this  the 
developer  creates  a  working  model  (prototype)  that  emulates  what  the  developer 
thinks  the  user  wants.  The  user  reviews  the  prototype  and  tells  the  developer 
what  he/she  likes  and  dislikes  about  the  system.  Based  upon  this  review  the 
developer  modifies  or  creates  a  new  prototype  for  the  user  to  review.  This 
process  continues  until  the  user  is  satisfied  with  the  presented  prototype.  With 
this  information,  the  developer  can  now  go  forward  and  develop  the  working 
system,  now  knowing  what  features  are  desired  in  the  system.  [Ref.  5:pp.  603- 
613] 

2.  Determining  System  Requirements 

A  manager’s  ability  to  make  quality  decisions  is  directly  related  to  the 
quality  and  availability  of  information  that  pertains  to  the  issue  at  hand. 

Without  having  the  right  information  at  the  right  time,  a  manager  is  unable  to 
carry  out  his/her  responsibilities  effectively.  This  identifies  two  general 
attributes  of  information.  The  information  must  be  "the"  information  that  the 
manager  needs  for  the  particular  decision  making  process  that  he/she  is 


61 


encountering.  And,  the  information  must  be  timely.  Timeliness  is  crucial, 
receiving  the  information  v/hen  there  is  not  adequate  time  for  the  manager  to 
take  advantage  of  a  situation,  or  to  correct  a  problem  is  unacceptable. 

All  managers  have  different  ideas  as  to  what  information  is  needed, 
and  when  the  information  is  needed,  in  any  given  situation.  The  variances  stem 
from  some  managers  having  a  better  feel  for  a  particular  situation,  or  maybe 
having  a  better  understanding  as  to  what  information  is  most  relevant.  Also  the 
level  of  experience  of  the  manager  will  impact  the  managers  information 
requirements.  Depending  on  the  level  of  diversity  in  the  organization  and  the 
dynamics  of  the  business  routine,  information  requirements  could  range  from  a 
very  stable  (a  very  systematic  and  well  established  routine),  to  a  very  dynamic 
organization  that  has  continually  changing  information  requirements. 

A  key  element  in  obtaining  the  system  that  the  user  needs  is  knowing 
what  the  user  wants  in  the  system.  Management  knows  that  they  need 
information  to  be  able  to  accomplish  their  jobs,  but  the  ability  of  managers  to 
clearly  state  what  information  they  need  on  a  routine,  periodic,  or  on  a  ad-hoc 
basis,  is  often  very  difficult  [Ref.  ll:pp.  98-99].  Without  clearly  identifying  what 
is  expected  out  of  an  AFMIS  prior  to  the  development  of  the  system,  it  is 
unlikely  that  the  system  being  developed  will  meet  the  needs  of  the  organization. 

Critical  Success  Factors  (CSF)  is  one  approach  that  can  assist  the 
development  team  in  determining  the  users  requirements.  CSF’s  are  important 
functions  within  the  organization  that  must  achieve  a  minimum  standard  to  be 
considered  successful.  CSF’s  are  derived  through  a  series  of  interviews,  focusing 
on  what  is  necessary  for  the  interviewee  to  be  successful  within  their  position. 
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By  determining  what  the  CSF’s  are,  it  is  possible  to  determine  the  information 
requirements  for  supporting  those  CSF’s.  [Ref.  12:pp.  6-8] 

Utilizing  only  the  CSF’s  is  not  enough  for  the  purpose  of  identifying 
all  of  the  requirements  of  an  AFMIS.  The  utilization  of  questionnaires  for 
management  to  respond  to,  will  provide  an  addition  means  of  evaluating  the 
information  needs  of  management.  The  questionnaire  will  provide  for  a  standard 
means  of  comparison  between  managers  to  evaluate  the  overall  needs  of  the 
organization.  [Ref.  4:p.  115] 

Another  source  for  determining  information  needs  is  by  collecting  all 
currently  prepared  reports  within  the  organization.  This  should  include  both 
currently  automated  reports  and  manually  prepared  reports. 

3.  Prioritization  of  Information  Requirements 

Once  all  of  the  requirements  are  identified  for  the  proposed  new 
system,  it  is  important  to  place  priorities  on  all  of  these  requirements.  The 
importance  of  this  is  that  it  might  not  be  economically,  or  technically  feasible  to 
accomplish  all  of  the  functionality  of  the  requested  system.  Without  a  priority 
listing,  approved  by  management,  the  development  team  may  incorrectly  choose 
which  application  to  develop  and  which  ones  not  to  develop. 

4.  Taking  Inventory  of  Existing  Hardware  and  Software  Systems 
Determining  the  hardware  systems  that  are  currently  within  the 

organization  will  influence  the  development  of  the  system.  With  an  inventory  of 
the  existing  computer  systems,  the  developers  will  be  able  to  determine  if  the 
existing  hardware  can  be  utilized  with  the  new  system  or  if  the  existing 
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hardware  will  need  to  be  replaced.  The  compatibility  of  hardware  systems  is  also 
an  important  concern  during  the  development  process. 

Taking  inventory  of  the  existing  software  applications  within  the 
organizations  is  important  for  two  reasons.  First,  if  there  are  applications 
currently  in  place  that  will  be  replaced  by  the  new  system,  there  will  be  a 
requirement  for  converting  the  current  system  and  information  over  to  the  new 
system.  Second,  some  of  the  current  applications  might  be  usable  in  the  new 
system.  Reusability  of  current  applications  could  reduce  both  the  development 
time  and  cost. 

5.  Evaluating  the  Feasibility  of  the  Proposed  System 

Throughout  the  development  process,  it  is  important  to  incorporate 
feasibility  check  points  to  ensure  that  the  project  is  both  feasible  and  affordable. 
With  any  system  development  project,  the  initial  estimates  are  often  inaccurate. 
As  the  development  of  the  system  progresses,  better  estimates  can  be  made. 

The  development  team  should  be  required  to  provide  the  requesting  activity  with 
the  projected  estimates  of  the  project  on  a  periodic  basis. 

With  each  feasibility  report,  the  requesting  command  should  closely 
review  the  revised  estimates.  The  activity  may  find  that  the  project  is  becoming 
to  costly,  based  upon  how  it  is  currently  proposed.  Decisions  of  reduction  of 
scope  or  even  cancellation  of  costly  projects  should  be  viable  alternatives  within 
the  decision  making  process. 

6.  Use  of  "Off-the-Shelf  Software”  vs.  In-house  Development 

In-house  developed  software  is  software  that  is  specifically  developed 

for  a  given  system.  In-house  development  requires  the  full  development 
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approach  which  includes:  determining  the  users  requirements  of  the  system; 
determining  the  logical  design  of  the  system  (determining  the  specifications  of 
the  requirements);  programmers  writing  the  programs  for  the  system;  program 
testing;  implementation  of  the  system;  and  maintenance  of  the  system.  In- 
house  development  can  be  performed  by  the  local  commands  computer 
specialists,  a  Navy  Regional  Data  Automation  Center  (NARDAC),  or  a  commercial 
contractor.  This  is  traditionally  a  very  lengthy  and  expensive  process. 

An  alternative  to  In-House  development  is  "OfF-the  Shelf  (OTS). 

There  is  a  multitude  of  OTS  software  products  in  the  commercial  market.  If 
possible,  the  use  of  an  OTS  application  can  possibly  reduce  the  time  and  expense 
of  a  project.  With  the  vast  number  of  available  OTS  applications  in  the 
commercial  market,  it  is  likely  that  there  are  OTS  applications  that,  with  some 
minor  modifications,  could  meet  the  needs  of  the  system  that  is  being  developed. 
To  use  OTS,  it  is  still  necessary  to  go  through  the  requirements  phase  of  the 
development  process.  With  out  doing  this,  it  would  not  be  possible  to  adequately 
determine  which  OTS  could  meet  the  requirements. 

B.  RECOMMENDED  FRAMEWORK  OF  AN  AFMIS 

An  AFMIS,  ideally,  should  encompass  all  three  levels  of  the  financial 
accounting  system.  That  is,  the  system  should  be  an  integrated  application  that 
links  the  cost  centers  with  the  Comptroller  department,  and  the  comptroller 
department  with  the  FIPC  system.  The  framework  that  is  recommended  here  is 
a  generic  framework  that  can  serve  as  a  tool  for  activities  to  conceptualize  an 
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AFMIS.  Figure  1  illustrates  the  Integrated  AFMIS  Framework.  The  framework 
is  briefly  discussed  here  at  both  the  comptroller  level  and  the  cost  center  level. 

1.  Cost  Center  AFMIS 

cl  Entry  of  Obligations 

Ideally  an  AFMIS  should  promote  the  philosophy  of  "one  time 
data  entry".  That  is,  data  should  only  have  to  be  entered  into  the  AFMIS  once. 
All  other  functions  that  need  to  utilize  that  data  should  be  able  to  have  access  to 
it  via  the  AFMIS. 

The  concept  of  one  time  data  entry  should  be  introduced  at  the 
cost  center  level.  The  cost  centers  are  the  origination  points  for  initiating 
obligations.  Since  cost  centers  need  to  keep  track  of  their  obligations  in  their 
local  accounting  system  (cost  center  memorandum  records),  the  entry  of  the 
obligation  into  their  AFMIS  should  also  serve  as  the  data  entry  into  IDA  (after 
review  by  the  Comptroller’s  accountants). 

If  properly  developed,  the  AFMIS  (at  the  cost  center  level)  can 
have  detailed  error  checking  routines  for  validating  the  information  that  is  being 
entered.  By  validating  the  data  at  the  cost  center  level,  data  entry  errors  can  be 
reduced.  If  errors  are  encountered,  the  user  can  correct  the  discrepancy  at  the 
terminal. 
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GENERIC  AFMIS  FRAMEWORK 


Figure  1  Generic  AFMIS  Framework 
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6.  Transaction  Listings 

Transaction  Listings  (TL)  should  be  automatically  forwarded  to  the 
cost  center  AFMIS  via  electronic  means  from  the  Comptroller’s  AFMIS. 

The  cost  center’s  AFMIS  can  be  developed  to  automatically 
compare  the  TL’s  with  the  information  contained  in  the  local  AFMIS.  The 
AFMIS  should  be  able  to  assist  in  the  reconciliation  of  the  TL’s,  and  generate  a 
hard  copy  listing  of  those  TL’s  that  require  further  action. 

Once  the  TL’s  are  reconciled,  the  AFMIS  should  pass  the 
corrections  to  the  Comptroller’s  AFMIS  for  review  and  approval  for  updating  the 
IDA  system. 

c.  Cost  Center  Report  Generation 

The  local  AFMIS  should  be  able  to  generate  management 
information  reports  for  the  cost  center’s  management.  These  reports  should  be 
able  to  be  tailored  to  the  particular  needs  of  the  cost  center. 

2.  Comptroller  AFMIS 

a.  Entry  of  Obligations 

With  obligations  being  entered  at  the  cost  center  level,  the 
Comptroller’s  accountants  will  serve  as  a  review  point  for  these  obligations.  The 
accountants  will  receive  the  obligations  via  the  AFMIS.  The  obligations  will  be 
reviewed  on  the  monitors  by  the  accountants  and  if  no  discrepancies  are  noted, 
the  obligations  are  forwarded  onto  the  IDA  system.  If  discrepancies  are 
identified,  the  obligation  is  rejected  and  sent  back  to  the  cost  center  for 
correction,  via  the  AFMIS. 
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Two  accounting  functions  are  taking  place  upon  completion  of  the 
review  of  the  obligations  by  the  accountants:  First,  the  activities  memorandum 
records  are  being  updated;  Second,  the  IDA  system  is  being  updated. 
b.  Transaction  Listings 

Transaction  Listings  should  be  electronically  received  from  the 
FIPC  system.  Upon  receipt  of  the  TL,  the  Comptroller’s  AFMIS  should  sort  the 
TL  into  cost  center  sequence.  The  sorted  TL  is  then  forward  to  the  cost  centers 
for  corrective  action. 

Once  the  cost  centers  have  reconciled  the  TLs,  the  Comptroller’s 
accountants  will  review  the  corrections  via  the  AFMIS.  If  no  discrepancies  are 
identified,  the  corrections  are  transmitted  to  the  IDA  system  for  update. 
cl  Management  Information  Reports 

The  report  generation  capability  should  be  flexible  so  that  it  can 
be  adapted  to  meet  managements  needs.  Also,  with  the  Comptroller’s  AFMIS 
monitoring  the  daily  transactions  at  both  the  activity  level  and  the  cost  center 
level,  the  AFMIS  should  be  able  to  generate  exception  reports  when  the 
conditions  warrant  it. 
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APPENDIX  AA  -  CHECK-OFF  LIST  FOR  AUTOMATING  A  FINANCIAL 
MANAGEMENT  INFORMATION  SYSTEM 

A.  SOLICITING  SUPPORT  FROM  TOP  MANAGEMENT 

_  Review  command  procedures  for  requesting  the  development  of  an 

automated  information  system.  The  local  Data  Processing  Center  will  have 
guidelines  for  the  proper  submission  of  requests. 

_  Obtain  Command  support  for  determining  requirements  of  proposed 

system  and  conducting  a  feasibility  study. 

B.  DETERMINING  REQUIREMENTS  OF  SYSTEM 
1.  Copies  of  Current  Reports 

_  Obtain  copies  of  all  current  financial  reports  (both  automated  and 

manual)  used  in  the  Accounting  Division 

_  Obtain  copies  of  all  current  financial  reports  (both  automated  and 

manual)  used  in  the  Budgeting  Division 

_  Obtain  copies  of  all  current  financial  reports  (both  automated  and 

manual)  used  by  the  Comptroller 

_  Obtain  copies  of  all  current  financial  reports  (both  automated  and 

manual)  presented  to  the  Commanding  Officer,  Executive  Officer,  and 
Department  Heads. 

_  Obtain  copies  of  all  current  financial  reports  (both  automated  and 

manual)  generated  for  submission  to  higher  authority. 


60 


2.  Input  From  Users  as  to  the  Desired  Capabilities  of  the  Proposed 
System 

_  Determine  the  Critical  Success  Factors  for  each  position  affected  by  the 

system.  Critical  Success  Factors  is  just  one  of  many  different  methodologies  to 
obtain  what  the  bare  minimum  requirements  would  be  from  the  users 
prospective. 

_  Use  a  questionnaire  to  solicit  desired  user  requirements.  The 

questionnaire  format  should  be  in  a  manner  that  will  lend  itself  for  comparison 
with  each  other  once  returned  from  the  user. 

_  Consolidate  all  user  identified  requirements,  then  have  the  users 

determine  the  priorities  of  the  requirements  that  they  requested. 

C.  TAKE  INVENTORY  OF  EXISTING  SYSTEMS 

_  Take  a  detailed  inventory  of  all  computer  hardware  currently  in-place 

(computers,  printers,  modems,  monitors,  etc.).  The  inventory  should  depict  type 
of  equipment,  quantity,  and  location. 

_  Take  a  detailed  inventory  of  current  applications  in  use.  The  inventory 

should  include  type  of  application,  location,  frequency  of  use,  who  the  users  are, 
and  the  intended  use  of  application. 

D.  INITIAL  FEASIBILITY  REPORT 

_  Does  the  feasibility  report  address  compatibility  of  the  proposed  system 

between  the  Comptroller  Department  and  the  Cost  Centers? 
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_  Does  the  feasibility  report  address  compatibility  of  the  proposed  system 

between  the  Comptroller  Department  and  IDA? 

_  Does  the  feasibility  report  address  the  cost  of  additional  hardware 

requirements? 

_  Does  the  feasibility  report  address  alternative  approaches  to  the  proposed 

system? 

_  Does  the  feasibility  report  address  the  development  methodology?  Will 

the  development  approach  be  Prototyping  or  System  Development  Life  Cycle? 
Prototyping  is  highly  recommended,  due  to  the  greater  involvement  of  the  user 
throughout  the  development  process. 

_  Does  the  feasibility  study  report  the  level  of  user  involvement  during  the 

project? 

_  Does  the  feasibility  report  address  the  anticipated  conversion  costs 

involved?  These  costs  would  include  transferring  over  any  data  in  the  current 
system  over  to  the  new  system  and  training  the  users  on  the  new  system. 

_  Does  the  feasibility  report  address  what  the  anticipated  maintenance  cost 

will  be  once  the  system  is  completed? 

_  Does  the  report  address  the  possibility  of  utilizing  "Off-the-Shelf" 

software? 

_  Does  the  feasibility  report  address  the  possibility  of  using  existing 

applications  within  the  proposed  system? 

_  Does  the  feasibility  report  address  the  possibility  of  incremental 

development?  Can  the  system  be  developed  by  functional  area  and  implemented 
once  those  areas  are  complete.  New  versions/releases  of  the  application  would 
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expand  the  capability  of  the  system.  This  approach  lends  itself  to  organizations 
that  do  not  have  adequate  funding  for  the  entire  project,  but  as  money  becomes 
available,  additional  modules  can  be  developed  and  implemented. 

E.  DETERMINATION  AS  TO  CONTINUE  WITH  THE  PROJECT 

_  Determine  if  the  cost  of  the  project  warrants  the  continuation  of  the 

development  effort. 

_  Determine  if  the  development  time  frame  is  acceptable.  If  there  are 

significant  changes  in  the  future  for  how  the  organization  will  be  required  to 
manage  their  financial  operation,  then  is  it  worth  the  cost  and  effort  to  develop 
the  proposed  system? 

_  Are  all  requirements,  identified  by  the  users,  going  to  be  met?  Are  any 

of  the  requirements,  determined  by  the  development  team,  infeasible?  If  so, 
without  these  requirements  is  the  system  still  worth  the  effort  and  cost? 
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APPENDIX  BB  •  LESSONS  LEARNED 
The  following  lesson’s  learned  are  from  Navy  shore  activities  that  have 
implemented  AFMIS’s.  This  list  is  provided  so  that  it  may  assist  an  organization 
in  their  development  effort  of  an  AFMIS. 

•  Potential  users  were  not  correctly  identified,  this  resulted  in  the  application 
not  meeting  all  of  the  user’s  requirements. 

•  The  developers  failed  to  identify  what  computer  systems  were  available  to 
the  users.  The  developed  application  ended  up  not  being  compatible  in  all 
cost  centers,  which  required  the  cost  centers  to  procure  additional 
equipment. 

•  Users  where  not  involved  in  the  development  process.  This  lack  of 
involvement  resulted  in  flawed  requirement  specifications. 

•  Developers  and  users  vocabulary  are  different.  This  resulted  in 
misinterpreted  requirements. 

•  The  developed  application  required  the  cost  centers  to  have  a  copy  of  a 
particular  software  package  to  use  the  AFMIS.  Several  cost  centers  did  not 
have  the  required  software  package,  and,  did  not  have  the  funding  to 
procure  the  required  package. 

•  The  developers  of  the  application  assumed  that  the  users  were  familiar  with 
computers  and  the  selected  "Off-the-Shelf"  software.  This  lead  to  the 
development  of  an  application  that  was  too  complex  for  the  average  user  to 
use. 

•  During  the  programming  of  the  application,  the  information  that  is  used  to 
validate  the  users  input  (for  error  checking)  was  programmed  as  part  of  the 
program’s  code  in  the  software  package.  Without  using  look-up  tables 
within  the  program  (which  is  easier  to  modify)  a  new  fiscal  year  required 
extensive  reprogramming  before  the  application  could  be  used. 

•  Failure  to  field  test  the  system  prior  to  full  implementation  resulted  in  an 
unreliable  product  that  users  refused  to  use. 

•  The  lack  of  scheduling  formal  training  resulted  in  the  implementation  of 
the  AFMIS  with  little  support  from  the  users.  It  was  assumed  that  the 
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users  would  be  interested  enough  in  the  new  AFMIS  to  obtain,  on  their 
own,  the  training  needed  for  the  new  system. 

•  Desk  guides  were  not  developed  for  users.  This  greatly  hindered  the 
implementation  process  and  user  acceptance. 

•  If  an  AFMIS  is  developed  that  has  a  high  user  acceptance,  enhancements  to 
the  system  must  be  planned  and  scheduled.  It  is  very  easy  to  continue  to 
enhance  an  existing  system,  but  this  prevents  the  development  of  others 
applications  that  are  competing  for  the  same  development  resources. 

•  The  development  approach  failed  to  keep  the  users  involved  through  out 
the  development  process.  This  resulted  in  a  loss  of  interest  by  the  users, 
which  made  acceptance  of  the  system,  once  implemented,  more  difficult. 

•  Use  of  the  developed  AFMIS  at  the  cost  centers  was  not  mandatory. 
Therefore  the  cost  centers  refused  to  convert  over  from  their  old/familiar 
system  to  the  new  system. 

•  There  was  no  documentation  for  the  AFMIS.  When  the  developer 
transferred,  there  was  no  one  knowledgeable  within  the  organization  to 
maintain  or  update  the  software. 

•  Backup  and  recovery  procedures  where  not  adequately  tested  prior  to 
implementation.  This  resulted  in  a  cost  center  having  to  re-enter  a 
significant  amount  of  data  into  the  AFMIS. 
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APPENDIX  CC  -  SAMPLE  MANAGEMENT  INFORMATION  REPORTS 
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Figure  4  Unmatched  Expenditures  by  Quantity 
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Figure  8  Cost  Center's  Operating  Target  Report 
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Figure  9  Reimbursable  Report 
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Figure  10  Management  to  Payroll,  Cumulative 
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Figure  13  Civilian  Personnel  Grade  Creep  Report 
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APPENDIX  DD  ■  COMPUTERS 


As  micro-computers  are  readily  available  in  most  organizations,  the 
emphasis  in  this  document  is  on  the  use  of  micro-computers,  also  known  as  desk¬ 
top  computers  or  personal  computers  (PC’s).  Even  though  this  paper  addresses 
micro-computers,  the  theory  is  the  same  for  all  computer  systems,  the  difference 
will  be  in  the  size  of  the  computer,  cost  of  the  computer,  and  the  amount  of 
information  that  can  be  processed  in  a  given  period  of  time. 

A  computer  is  a  tool.  If  understood  and  used  properly,  a  computer  can 
assist  in  conducting  a  multitude  of  repetitive  tasks  in  a  very  fast  and  efficient 
manner.  A  computer  is  an  electronic  device  that  follows  very  explicit 
instructions. 

Since  a  computer  is  an  electronic  piece  of  hardware,  a  computer  does  not 
have  the  ability  to  think  or  make  decisions  on  its  own.  A  computer  can  only 
differentiate  the  difference  between  electrical  voltage  levels  in  circuits.  And 
based  upon  these  voltage  levels,  the  computer  can  translate  these  into 
understandable  instructions.  The  different  voltage  levels  in  the  computer 
represents  l’s  and  0’s.  With  the  proper  combination  of  l’s  and  0’s,  the 
computer  is  able  to  understand  and  perform  a  function  for  the  operator  of  the 
computer.  (The  term  ’operator’  is  a  general  term  that  identifies  the  person  that 
is  operating  the  computer.  The  term  ’user’  in  respect  to  micro-computers  is  also 
the  operator.)  Each  possible  1  or  0  is  called  a  bit.  A  combination  of  eight  l’s  or 
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O’s  is  called  a  Byte.  A  group  of  l’s  and  0’s  that  perform  a  function  within  the 
computer  is  call  a  computer  instruction.  It  usually  takes  more  then  one  byte  to 
make  up  an  instruction.  And  it  takes  thousands  to  millions  of  instructions  to 
make  up  a  program,  depending  on  the  size  of  the  application. 

There  are  several  components  to  a  computer  system  that  must  interface  to 
provide  the  service  that  the  users  are  asking  of  the  computer.  The  overall 
picture  of  these  components  are  shown  in  Figure  #  1.  Each  component  will  be 
described  so  that  the  reader  will  have  a  general  understanding  of  how  a 
computer  works.  First  the  heart  of  the  computer,  which  is  called  the  Central 
Processing  Unit,  will  be  discussed.  This  will  be  followed  with  a  discussion  of  the 
other  four  components. 

1.  Central  Processing  Unit  (CPU) 

The  Central  Processing  Unit  (commonly  referred  to  as  the  CPU)  is  the 
heart  of  the  computer.  The  CPU  is  the  component  that  evaluates  and  executes 
the  instructions  of  a  program.  The  CPU  is  designed  to  interpret  the  series  of  l’s 
and  O’s  and  based  upon  the  evaluation,  it  will  perform  some  action.  This  action 
could  be  one  of  a  thousand  different  things,  such  as  add  a  number,  subtract  a 
number,  request  a  new  instruction;  etc..  The  key  here  is  that  the  CPU  is  where 
all  of  the  instructions  are  processed. 

All  CPU’s  are  not  the  same.  There  are  several  different  manufacturers 
that  have  designed  and  marketed  their  CPU.  Since  the  CPU  is  the  heart  of  the 
system,  computers  are  designed  around  the  CPU.  This  is  so  that  the  computer 
can  take  full  advantage  of  the  capabilities  of  the  of  the  CPU.  Fortunately,  in  the 
80’s,  the  Navy’s  procurement  practices  resulted  in  a  standard  in  micro-computers 
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Figure  1  Components  of  a  computer  system. 


in  the  Department  of  the  Navy  (DoN).  The  minority  of  all  micro-corr-  ;  aters 
purchased  in  the  Navy  were  and  still  are  IBM  compatible.  This  mea/.s  that  the 
micro-computers  that  are  being  purchased  have  a  Central  Processing  Unit  that 
executes  IBM  compatible  software  (software  that  operates  under  the  IBM  Disk 
Operating  System  (IBM-DOS)  or  under  the  Microsoft  Disk  Operating  System 
(MS-DOS),  which  are  discussed  later  in  this  chapter). 

Due  to  the  Navy’s  purchasing  practices,  there  are  three  CPU’s  that 
will  be  encountered  Navy  activities.  All  three  are  manufactured  by  the  Intel 


Corporation.  The  CPU’s  are  labeled  Intel  8086,  Intel  80286,  and  Intel  80386 
(Intel  is  currently  developing  the  Intel  80486,  which  will  not  be  discussed  here). 

a.  Intel’s  8086  CPU  (PC,  PC/XT) 

The  processor  used  in  the  IBM-PC,  in  the  early  80’s,  was  the 
Intel  8086.  Compared  to  today’s  standards,  this  is  considered  a  slow  processor 
for  desk  top  applications.  The  IBM-PC  (PC,  stands  for  IBM-PC  or  compatible) 
was  limited  in  its  ability  to  expand  (not  because  of  the  CPU  but  because  of  the 
design  of  the  computer  around  the  CPU).  As  a  result,  IBM  redesigned  the  PC 
and  came  out  with  the  IBM-PC/XT  (XT,  stands  for  IBM-PC/XT  or  compatible). 
The  XT  used  the  same  CPU  as  the  PC,  but  it  had  the  flexibility  to  add 
additional  peripherals  (peripherals  are  hardware  components  such  as  disk  drives, 
modems,  mouse,  etc.,  which  will  be  discussed  later  in  this  chapter). 

b.  Intel’s  80286  CPU  (AT) 

In  the  mid  80’s  Intel  released  the  80286  CPU.  This  processor, 
along  with  the  improved  computer  architecture  designed  around  it,  was 
significantly  faster  then  the  8086.  This  new  computer  was  classified  as  the  IBM- 
AT  (AT,  stands  for  EBM-AT  or  compatible).  There  were  several  hardware 
innovations  during  the  refinement  of  the  AT,  such  as  high  capacity  floppy  disk 
drives  and  access  to  additional  memory  (both  are  discussed  later  in  this  chapter). 

The  majority  of  software  designed  for  use  on  the  PC  and  XT  can 
be  used  on  the  AT.  Recently,  software  has  been  developed  to  exploit  the 
capability  of  the  80286  processor.  Specific  applications  for  the  AT  will  not  be 
usable  (will  not  be  compatible)  on  the  PC  or  XT. 
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c.  Intel’s  80386  CPU  (386) 

In  the  past  two  years  Intel  has  been  promoting  a  new  CPU,  the 
80386  processor.  This  processor  has  improved  capabilities  over  the  80286 
processor.  The  computers  that  are  built  around  this  processor  are  commonly 
referred  to  as  386  machines.  386  computers  are  faster  then  AT  machines.  But 
the  significant  change  that  was  introduced  in  the  386  was  "multi-tasking".  This 
is  where  more  then  one  program  can  run  at  the  same  time.  As  with  the  80286, 
the  386  is  backward  compatible,  which  means  that  it  can  execute  programs  that 
were  designed  for  the  PC,  XT,  and  AT.  Programs  written  explicitly  for  the  386 
will  not  be  useable  on  the  previous  computers. 

2.  Computer  Memory 

All  computers  have  a  set  of  transistors  that  are  specially  designed  to 
store  the  electric  voltages  that  represent  the  l’s  and  0’s  for  the  computer  to 
work  from.  On  a  micro-computer,  machines  have  640K  (640,000  bytes)  of 
memory,  others  with  more  and  others  with  less.  This  number  represents  the 
number  of  transistors  in  the  machine  to  temporarily  store  the  instructions  and 
data  that  was  entered  into  the  machine. 

When  a  program  is  loaded  into  a  computer,  the  program  is  being 
loaded  into  memory,  call  Random  Access  Memory  (RAM).  When  the  operator 
runs  a  program  (after  it  has  been  loaded  into  the  computer)  the  instructions  for 
the  program  are  coming  from  the  RAM  and  the  data  that  is  being  enter  is  also 
being  stored  into  the  RAM. 

The  amount  of  RAM  needed  depends  on  the  software  package  that  the 
operator  decides  to  use  and  the  amount  of  data  that  will  be  handled.  Once  the 
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operator  knows  what  the  application  requirements  are,  the  operator  should  go  to 
the  Automated  Data  Processing  Center  within  their  command  and  ask  for  their 
advice. 

Note  that  RAM  is  temporary.  When  a  machine  is  turned  off,  the 
program  and  data  are  lost.  When  a  new  application  is  loaded  into  the  computer, 
the  previous  application  and  data  will  be  removed.  Permanent  storage 
techniques  are  discussed  next. 

3.  Peripherals 

Peripheral  are  hardware  components  that  are  attached  to  the  computer 
to  perform  some  task.  Peripherals  fall  into  three  categories:  storage  devices; 
input  devices;  and  output  devices. 

a.  Storage  Devices 

A  storage  device  is  any  mechanism  that  is  attached  to  a  computer 
that  makes  it  possible  to  save  and  reuse  programs  and  data.  There  are  several 
storage  devices  on  the  market.  This  document  will  focus  on  the  more  common 
or  soon  to  be  common  storage  devices.  All  storage  devices  work  on  a  basic 
technology  of  a  tape  recorder.  By  using  the  tape  recorder  as  an  example,  an 
illustration  as  to  how  computers  saves  data  can  be  made. 

A  tape  recorder  works  in  the  following  manner:  As  the  recorder 
picks  up  the  music  that  is  being  played  with  the  microphone,  the  tape  recorder 
circuits  codes  the  music  into  electronic  signals.  These  electronic  signals  are  sent 
to  the  recording  head  which  in  turn  generates  a  magnetic  field.  This  magnetic 
field,  on  the  recorder  head,  changes  as  the  signals  change  in  respect  to  the 
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music.  As  the  tape  passes  under  the  recorders  head,  the  magnetic  characteristics 
of  the  tape  change.  This  change  on  the  tape  captures  the  magnetic  signals. 

Due  to  the  properties  of  the  tape,  the  magnetic  signal  is  retained 
on  the  tape  for  a  lengthy  period  of  time.  The  storage  life  of  the  recording  is 
affected  by  the  quality  of  the  tape  and  how  the  tape  is  handled  and  stored.  This 
is  how  music  is  saved  and  stored  for  future  use. 

For  retrieving  the  data  on  the  tape  (in  this  case,  the  music)  the 
process  is  reversed.  The  tape  passes  under  the  head  of  the  recorder,  and  the 
head  now  senses  the  magnetic  fields  on  the  tape  and  translates  these  signals  in 
signals  that  the  recorder  can  understand.  Now  the  recorder  can  recreate  the 
music. 

The  long  term  storage  devices  used  in  micro-computers  are 
traditionally  disk  drives.  They  are  called  disk  drives  because  of  the  storage 
medium  used,  it  is  in  the  shape  of  a  round  disk.  All  disk  drives  use  the  same 
principles  of  operation.  They  store  data  much  like  the  tape  recorder  but  instead 
of  having  one  continuous  tape  to  record  onto,  the  disks  are  divided  up  into 
tracks,  see  Figure  2.  These  tracks  work  the  same  as  a  tape  in  the  tape  recorder, 
the  difference  is  that  when  more  tape  is  required,  the  recording  head  (read/write 
head)  can  travel  (move)  to  another  track  to  continue  the  save  or  read  process. 

Over  time,  the  technology  used  to  develop  and  produce  disk  drives 
improved.  This  technology  has  introduced  various  types  of  disk  drives  on  the 
market.  As  a  result,  a  user  needs  to  be  aware  of  the  basic  differences  between 
them. 
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Illustration  of  a  Computer  Disk  Drive 
and  Disk 

Tracks 


Figure  2  Example  of  a  Disk  Drive  and  Disk 

Disk  drives  fall  into  three  common  categories,  hard  disk  drive 
(also  referred  to  as  fixed  disk  or  Winchester  drives)  which  is  permanently 
installed  in  the  computer  and  can  not  be  easily  removed;  floppy  disk  drives,  and 
optical  disk  drives. 

(1)  Hard  Disk  Drives  Hard  disk  drives  are  traditionally  installed 
internally  to  the  computer.  These  are  usually  not  removable  (there  are  a 
limited  number  of  removable  hard  disk  drives  on  the  market  but  are  not 
frequently  used  in  the  DoN).  Hard  disk  drives  receive  their  name  from  the 
type  of  recording  medium  used  in  them.  Like  all  other  disk  drives,  hard  disk 
drives  use  a  round  disk  (or  several  round  disks  layered  on  top  of  each  other). 
The  difference  is  that  the  disk  is  made  out  of  hard  metallic  material  versus  a 
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floppy  disk  that  is  made  of  a  flexible  recording  material.  The  properties  of  the 
hard  disk  drives  make  it  possible  to  save  far  greater  quantities  of  data  compared 
to  floppy  disk  drives.  Hard  disk  drives  have  a  storage  capability  ranging  from  10 
million  bytes  of  information  up  to  several  hundred  million  bytes  of  information 
(floppy  disks  have  a  capacity  ranging  from  360,000  to  1.4  million  bytes). 

(2)  Floppy  Disk  Drives  Floppy  disk  drives  received  this  label 
because  of  the  flexible  recording  medium  used.  One  of  the  primary  advantages 
of  floppy  disk  drives  is  that  the  recording  medium  is  easily  removable.  This 
makes  it  possible  to  enter  and  store  data  at  one  micro-computer,  save  the  data  to 
the  floppy  disk,  remove  the  floppy  disk,  then  place  the  floppy  disk  into  a 
different  computer  for  retrieval  of  information. 

In  the  early  80’s  the  standard  for  floppy  disk  drives  was  a  5 
1/4"  disk  drive  that  had  a  storage  capacity  of  360,000  bytes  of  information  (360K 
disk  drive).  By  the  mid  80’s  a  new  5  1/4"  floppy  disk  drive  was  developed  that 
had  a  storage  capacity  of  1.2  million  bytes  of  information  (often  referred  to  as  a 
"high  density  disk  drive").  The  technology  of  the  high  density  disk  drive  internal 
components  was  improved  and  the  high  density  5  1/4"  disks  also  had  to  be  of  a 
higher  quality.  The  computer  industry  made  it  possible  for  the  new  High 
Density  disk  drives  to  be  able  to  retrieve  and  store  data  on  the  360K  disks.  But, 
due  to  the  characteristics  of  the  new  high  density  disks  and  disk  drives,  it  is  not 
possible  to  retrieve  and  store  data  off  a  high  density  disk  in  a  360K  disk  drive 
(unless  the  high  density  disk  is  used  as  a  360K  disk). 
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A  second  size  floppy  disk  was  developed  in  the  mid  80’s,  the 
3  1/2"  floppy  disk.  This  new  disk  and  disk  drive  has  a  720,000  byte  storage 
capability  (720K).  This  floppy  disk  resulted  in  a  smaller  and  improved  diskette. 
This  diskette,  unlike  the  flexible  5  1/4  "  disk,  is  protected  with  an  improved  hard 
plastic  casing.  This  disk  is  not  compatible  with  either  5  1/4"  disk  drives.  In  the 
late  80’s,  the  3  1/2"  disk  drive  was  also  improved.  A  high  density  version  of  the 
3  1/2"  disk  drive  was  made  available.  This  high  density  version  has  a  1.4  million 
byte  storage  capacity.  And  like  the  5  1/4"  drives,  the  high  density  3  1/2"  disk 
drives  can  use  the  720K  disks  but  the  720K  disk  drive  can  not  read  the  data 
stored  on  the  high  density  disks. 

(3)  Optical  Disk  Drives  The  current  state  of  the  art  in  storage 
medium  is  in  the  area  of  optical  disk  drives.  There  are  currently  two  basic  types 
of  optical  disk  drives;  the  Compact  Disk  -  Read  Only  Memory  (CD-ROM)  and  the 
Write  Once,  Read  Many  (WORM).  These  disk  drives  use  laser  technology,  much 
like  the  compact  disk  players.  CD-ROM  is  more  of  a  data  repository.  CD-ROM 
does  not  have  the  ability  to  store  information  that  is  in  the  computer.  As  the 
ROM  indicates,  Read  Only  Memory,  the  computer  can  only  access  the  compact 
disk  and  retrieve  information  from  it.  The  information  is  traditionally  provided 
for  by  a  commercial  or  government  source  that  is  used  by  more  then  one 
command. 

Unlike  CD-ROM,  the  WORM  disk  drive  has  the  ability  to 
store  data  that  is  in  the  computer  much  like  a  hard  disk  drive.  The  Worm  disk 
drive  has  the  ability  to  store  approximately  500  million  bytes  of  data 
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b.  Input  Devices 

An  input  device  is  anything  that  is  attached  to  the  computer  that 
makes  it  possible  to  input  data  or  a  program  into  the  computer.  All  input 
devices  are  similar  in  purpose  but  are  quite  different  in  appearance  and  use. 

The  basic  purpose  of  an  input  device  is  to  convert  data  or  information  from  one 
medium,  such  as  information  on  a  document,  into  electronic  signals  that  the 
computer  can  recognize  and  use.  Then  the  device  sends  that  signal  to  the 
computer  for  processing.  To  illustrate  this,  lets  look  at  the  most  easily 
recognized  input  device,  the  keyboard,  followed  by  a  couple  other  input  devices. 

(1)  Keyboard  A  keyboard  is  an  electronic  device  that  sends 
electronic  signals  to  the  computer  each  time  a  key  is  pressed.  Each  time  a  key 
is  pressed,  the  keyboard  generates  the  proper  group  of  l’s  and  0’s  so  that  the 
computer  recognizes  that  particular  key  stroke.  There  are  a  multitude  of 
different  keyboards  that  can  be  used  on  several  different  systems.  The  selection 
of  the  keyboard  is  primarily  a  matter  of  preference,  as  long  as  the  keyboard  is 
compatible  with  the  system  that  it  will  be  connected  to. 

(2)  Mouse  A  mouse  is  an  input  device  that  is  primarily  used  as 
a  semi-substitute  for  the  keyboard.  The  mouse  is  a  hand  held  device  that  is 
attached  to  the  computer  via  a  wire.  The  mouse  is  moved  around  on  the  desk 
top  which  in  turns  moves  a  cursor  or  an  arrow  on  the  screen.  By  pressing  a  set 
of  buttons  on  the  mouse,  the  user  is  able  to  invoke  some  predetermined 
functions  that  would  normally  be  invoked  at  the  keyboard.  The  mouse  was 
designed  to  make  it  easier  for  the  user  to  select  options  or  move  items  around 
on  the  screen.  The  greatest  strengths  of  a  mouse  is  when  it  is  used  in  a 
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graphics  application.  For  use  in  applications  that  are  ledger,  data  base,  or  word 
processing  oriented,  the  use  is  traditionally  limited  to  menu  selections  and 
highlighting  text  or  numbers. 

(3)  Optical  Scanners  Optical  Scanners,  also  referred  to  as  Bar 
Code  Readers,  are  becoming  more  common  in  the  business  community.  The 
device,  which  may  be  hand  held  or  stationary,  uses  a  light  beam  to  analyze  a 
series  of  lines  that  are  specifically  printed  in  a  way  that  the  scanner  can  read 
the  coded  item.  This  device  is  vised  in  situations  where  there  is  a  definable  set 
of  characters  or  numbers  that  need  to  be  entered  into  the  computer  many  times 
over.  With  the  use  of  bar  code  scanners,  this  eliminates  the  possibility  of 
incorrectly  entering  the  code  into  the  computer  by  mistyping  the  code  from  the 
keyboard.  This  device  is  commonly  used  in  the  civilian  sector  and  is  currently 
being  used  in  various  parts  of  the  Navy  today. 

(4)  Optical  Character  Reader  The  Optical  Character  Reader 
(OCR)  is  a  device  that  can  recognize  characters  and  numbers  on  a  piece  of  paper. 
The  device  scans  the  document  and  by  use  of  both  hardware  and  software,  it  is 
able  to  identify  the  data  on  the  paper,  convert  the  data  to  electronic  signals, 
then  finally  send  that  signal  to  the  computer.  OCR’s  are  costly  and  if  everything 
is  not  perfect  on  the  document  that  is  being  scanned  (in  respect  to  how  the 
scanner  is  setup)  then  the  system  is  prone  to  error. 

(5)  Modem  A  user  may  already  have  data  that  is  electronically 
encoded,  in  that  it  has  already  been  entered  into  another  computer  system.  A 
device  called  the  Modem  can  bridge  the  gap  between  a  local  computer  and  a 
remote  computer.  A  modem  can  connect  the  computer  with  the  remote 
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computer  via  telephone  lines  (assuming  that  the  remote  computer  is  equipped 
with  a  modem,  and  can  be  made  compatible  with  the  users  modem). 

A  modem  is  a  hardware  device  that  is  connected  to  the 
computer  (it  can  be  installed  inside  the  computer  or  be  installed  external  to  the 
computer)  and  also  connected  to  a  telephone  line.  A  modem,  via  use  of  software, 
has  the  ability  to  contact  a  remote  computer,  request  the  data  that  a  user  wants, 
and  receive  that  data.  The  modem,  with  its  software  package  handles  the  signal 
conversion  over  the  telephones  in  a  manner  that  is  transparent  to  the  user.  The 
modem  also  has  the  capability  of  transmitting  information  to  other  computers, 
which  makes  the  modem  also  an  output  device, 
c.  Output  Devices 

An  output  device  is  anything  that  is  attached  to  a  computer  that 
makes  it  possible  for  the  computer  to  export  data/information  from  the 
computer.  Some  easily  recognizable  output  devices  are  printers,  plotters,  and 
monitors.  These  devices  provide  visible  information  to  a  user  in  the  form  of 
electronic  display  or  paper  type  presentations. 

4.  Operating  System  Software 

There  are  several  different  components  to  a  computer,  but  how  does 
the  computer  control  these  different  pieces  of  hardware?  How  does  it  know 
when  to  pull  data  from  a  disk  drive?  How  does  the  computer  know  where  to  go 
cn  the  disk  drive  to  save  or  retrieve  the  data?  How  does  the  computer  know  to 
look  for  input  from  the  keyboard,  mouse,  scanner,  or  modem?  And  how  does  the 
computer  know  when  to  send  something  to  the  monitor  or  printer?  The  answer 
to  all  of  these  questions  is  in  a  software  package  called  the  Operating  System. 


The  operating  system  is  specifically  designed  to  handle  these  type  of  issues. 

Since  a  computer  can  only  perform  one  task  at  a  time,  the  operating  system 
makes  it  possible  for  the  computer  to  schedule  and  manage  its  tasks.  The 
operating  system  monitors  the  requests  placed  upon  the  computer  and  handles 
the  details  of  telling  the  computer  what  to  do  and  when  to  do  it. 

There  are  several  different  operating  systems  on  the  market.  All  of 
them  are  designed  with  special  features  and  capabilities.  The  two  that  are 
widely  used  in  Comptroller  department  micro-computers  are  Microsoft’s  MS-DOS 
(Microsoft  Disk  Operating  System)  and  IBM’s  IBM-DOS,  which  is  the  same  as 
MS-DOS  except  it  is  marketed  by  IBM.  A  third  operating  system  is  called  OS/2, 
which  stands  for  Operating  System  2.  OS/2  is  being  developed  by  Microsoft,  and 
is  the  possible  replacement  for  MS-DOS  in  the  80386  and  newer  CPU’s. 

Operating  systems  acts  as  the  interface  between  the  computer  and 
application  programs.  Programs  use  the  capabilities  of  the  operating  system  to 
perform  the  low  level  tasks  of  managing  the  different  parts  of  the  computer 
system.  This  means  that  programs  are  written  with  a  specific  operating  system 
in  mind.  So,  if  a  user  attempts  to  use  a  program  under  a  different  operating 
system  then  intended,  the  results  are  unpredictable.  All  software  packages 
clearly  specify  which  operating  system  it  was  intended  for. 

5.  Computer  Programs  and  Data 

Computers  must  be  told  what  to  do,  how  to  do  it,  and  when  to  do  it. 
Over  the  years,  the  effort  that  was  required  for  the  user/operator  to  provide  the 
instructions  to  the  computer  to  perform  a  task  has  been  greatly  reduced.  This 
has  been  achieved  though  the  development  of  computer  programs  (software).  A 
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computer  program  is  a  series  of  instructions  encoded  in  a  manner  that  the 
computer  can  understand.  Programs  are  written  by  trained  people  called 
programmers.  Programmers  create  a  program  with  a  specific  purpose  in  mind. 

With  the  advent  of  the  micro-computer,  thousands  of  programs  have 
been  written  for  both  corporate  and  private  use.  Commercially  available 
programs  for  micro-computers  fall  into  two  broad  categories.  First,  programs  that 
are  designed  for  a  specific  task.  The  purchaser  has  a  very  specific  function  that 
needs  to  be  automated.  The  user  has  very  little  flexibility  in  modifying  the 
program  to  meet  their  desires.  The  following  are  some  examples  of  this  type  of 
programs:  word  processors;  tax  preparation  packages;  inventory  control; 
telecommunication  programs  for  communicating  between  different  computers. 

The  second  category  of  software  help  a  user  develop  an  application 
that  meets  a  specific  need.  Examples  are:  spreadsheet  programs  that  give  the 
user  the  ability  to  automate  ledgers,  track  and  manipulate  figures,  and  present 
figures  in  a  graphical  manner;  database  management  programs  which  gives  user 
the  ability  to  efficiently  store  and  retrieve  various  records/files  within  a 
computer  system. 

Which  type  of  program  to  select  for  use  in  a  Comptroller’s  department 
depends  on  the  particular  application  that  is  being  automated.  To  select  the 
program  to  use,  the  user  needs  to  address  both  the  requirements  and  capacity  of 
the  system  to  be  developed.  Once  this  is  known,  it  is  best  to  consult  with  the 
staff  in  the  local  computer  center  for  their  recommendations. 
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